From owner-freebsd-standards Thu Dec 6 0: 7: 7 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 8048E37B416 for ; Thu, 6 Dec 2001 00:06:59 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB686uG08800 for ; Thu, 6 Dec 2001 03:06:57 -0500 (EST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA19990; Thu, 6 Dec 2001 19:06:12 +1100 Date: Thu, 6 Dec 2001 19:06:39 +1100 (EST) From: Bruce Evans X-X-Sender: To: Wes Peters Cc: Garance A Drosihn , Bill Fenner , , Subject: Re: strerror_r() implementation In-Reply-To: <3C0D0995.A7FEFB47@softweyr.com> Message-ID: <20011206183558.N14527-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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