Date: Thu, 6 Dec 2001 19:06:39 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Wes Peters <wes@softweyr.com> Cc: Garance A Drosihn <drosih@rpi.edu>, Bill Fenner <fenner@research.att.com>, <mike@FreeBSD.org>, <freebsd-standards@bostonradio.org> Subject: Re: strerror_r() implementation Message-ID: <20011206183558.N14527-100000@gamplex.bde.org> In-Reply-To: <3C0D0995.A7FEFB47@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Dec 2001, Wes Peters wrote: > Bruce Evans wrote: > > Individual rules have precedence over general ones. > > That would be fine, if there were indeed an individual rule. Please feel > free to commit one at any time. The example (of "return (eight)") implicitly gives a rule. > > I think the contents of the buffer is indeterminate when strerror_r() > > fails. POSIX-1.200x-draft7 is not completely clear on this. > > The POSIX specificaion Mike mailed to me said "indeterminate". Not > nul-terminated seems consistent with "indeterminate", and is documented > as so in the man page. Which POSIX specification? > > strerror_r() is also permitted to fail if the error number is invalid. > > It must then return EINVAL. So the conversion to ASCII is not needed > > for strerror_r(), and it may be considered a bug that strerror_r() > > doesn't fail for bogus error numbers. However, the conversion is > > needed for strerror(). > > Which leads to an interested conundrum about what "invalid" might be. > Is an errno not in the system list "invalid" or just "not predefined?" > Does the POSIX specification lead us off this slippery slope, or should > the handling of errnos >= sys_nerr be moved to strerror? "valid" is not specified POSIX.1-200x-draft7 (except in some special context), so it has its normal English meaning. > > Here is my current version of the cleanups for strerror(). New changes: > > - don't resever bogus extra space for UPREFIX in ebuf[]. > > - fix breakage of reentrancy of strerror_r() in previous verions (tmp[] > > must be auto). > > But this one seems to be dependent on the non-conforming behavior > of strerror_r you have noted. It only depends on strerror() knowing the implementation details of strerror_r(). > I have attached a rewritten version in which strerror_r returns a message > only for "known" errors, otherwise it returns EINVAL. The "unknown" > message rendering code has been returned to strerror. The number buffer > has been sized appropriately at 21 characters, and the static buffer > is just long enough to hold the "Unknown error: " message plus the > number. I have even obfuscated all returns with unnecessary ()s for > Bruce. > > strerror is no longer implemented in terms of strerror_r since the > requirements are so divergent. Please review at your leisure. Once > we agree this is "good enough" I'll commit it. I'd prefer to be able > to MFC this before the 4.5 freeze. I agree that this is an improvement but not that it is "good enough". The best thing about it is that it makes strerror() self-contained again, so most of the style bugs are now easy to fix by reverting to the version of sterror() in rev.1.4. It makes the dubious non-cosmetic change not using sys_errlist[0] in either strerror_r() or sterror(), so an error code of 0 is now considered invalid for strerror_r(), and the string returned by strerror(0) is changed from "Undefined error: 0" in sys_errlist[0] to "Unknown error: 0" generated in strerror(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011206183558.N14527-100000>