Date: Fri, 07 Dec 2001 00:41:01 -0700 From: Wes Peters <wes@softweyr.com> To: Bruce Evans <bde@zeta.org.au> 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: <3C10728D.56A8FDF1@softweyr.com> References: <20011206183558.N14527-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
>
> 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.
The example of "return (eight)" implicitly says nothing. It's two
tiny characters buried in the middle of a lot of text that is
EXPLICITLY pointing out several unrelated rules. Make it an EXPLICIT
rule in style(9) or stop beating people up about it. You're being an
ass about this. I do not understand why you think it is appropriate
to be sly about this when it would be quite simple to just make a
simple, explicit statement.
> > > 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?
1003.1-200x Draft June 14, 2001. Upon careful reading, this is completely
silent on the issue of what happens with strerrbuf if insufficient space
is allowed to contain the string. That's pretty much the ultimate in
indeterminate. This implementation fills in as much of sys_errlist as
will fit and properly nul-terminates it. I have updated the man page to
more accurately describe what is done.
> > > 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.
So this is an untestable requirement and any particular choice we make
is as conforming as any other. Love those specs. It seems that strerror
is required to set errno to EINVAL if "The value of errnum is not a valid
error number." I have implemented this as well.
> > 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.
In spite of the style rants you held against the version of strerror() in
rev. 1.4? Or are EXISTING style nits somehow less worrisome than new
style nits? Is it that somehow in your mind the programmers of the past
are so much better than those of the current that their style bogons are
acceptable while ours are not?
Since strerror doesn't properly set errno, it is not Posix complaint in
rev. 1.4, so this is not a solution either.
> 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().
Easily enough fixed. I somehow imagined having "Undefined error: 0"
use the same message as "Undefined error: 437" to be an improvement.
sys_errlist messages will be used where 0 <= errnum < sys_nerr, and I
have documented this as the "recognized range" in the man page.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3C10728D.56A8FDF1>