Date: Tue, 4 Dec 2001 14:05:00 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Wes Peters <wes@softweyr.com>, Bruce Evans <bde@zeta.org.au> Cc: Bill Fenner <fenner@research.att.com>, mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation Message-ID: <p0510100cb832c9f7c119@[128.113.24.47]> In-Reply-To: <3C0D0995.A7FEFB47@softweyr.com> References: <20011203005459.N8502-100000@gamplex.bde.org> <3C0D0995.A7FEFB47@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:36 AM -0700 12/4/01, Wes Peters wrote:
>Bruce Evans wrote:
> > On Sat, 1 Dec 2001, Garance A Drosihn wrote:
>>
> > > Hmm. I do not have the standards document for strerror_r(), but I am
>> > surprised that a short buffer is expected to return a string which is
>> > not null-terminated. Note that I am not arguing the point, I'm just
>> > surprised. That means all callers to strerror_r() should never treat
>> > the result as a null-terminated string, even though it usually will
>> > be null-terminated. Seems to me that is asking for trouble.
>>
>> 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.
Well, I understand what "indeterminate" means. It means you can
have anything there. Anything. Elvish runes, if you wish. Fine.
The fact that the standard says "indeterminate" can not be offered
as proof that this particular decision is the "most desirable" one.
I merely wanted to offer an alternate opinion as what might be a safer
implementation. "Safer" is just as consistent with "indeterminate"
as is "not null-terminated".
I would present a case that it might be better if we happened to choose
to say the buffer will always be null-terminated, but you seem to be
loaded for bear on this topic, and I don't wish to seem like I am also
loaded for bear. I do think it will be good to get strerror_r() done,
and appreciate the work you've done.
I will note that in your own patch you have:
> memset(mybuf, '*', 63); mybuf[63] = '\0';
> strerror_r(11, mybuf, 64);
> printf("strerror_r(11) yeilds: %s\n", mybuf);
>
> memset(mybuf, '*', 63); mybuf[63] = '\0';
> ret = strerror_r(1234, mybuf, 64);
> printf("strerror_r(1234) returns %d (%s)\n", ret, mybuf);
>
> memset(mybuf, '*', 63); mybuf[63] = '\0';
> ret = strerror_r(1, mybuf, 10);
> printf("strerror_r on short buffer returns %d (%s)\n", ret, mybuf);
If I understand you right, then you are saying that this implementation
of strerror_r() may return a full "mybuf", which will not have any null
character in it. If that is our implementation, then I would think that
every call to strerror_r() should check the return code, and if the
return code is not zero then it should treat the buffer as a constant-
width string (ie, a string which does not necessarily have a null
character in it). So, not just the last call here, but all of the
calls should be checking the return code before doing anything with
the buffer. Our implementation claims that it is "laziness" on the
part of the programmer to not check that return code, and yet our own
example shows that laziness. "We know" that the buffer is long enough,
so we assume we don't have to check. What happens if someone changes
strerror to localize all the messages (to german, or Ent), and those
longer messages no longer fit in the buffer "we know" to be long enough?
Just my 2 cents. I don't meant to be argumentative just to rain on your
parade. I am just trying to make some observations here without seeming
to be ungrateful for the work you're doing.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
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?p0510100cb832c9f7c119>