This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Pino Toscano <toscano dot pino at tiscali dot it>
- Cc: bug-hurd at gnu dot org, libc-alpha at sourceware dot org
- Date: Fri, 20 Jul 2012 10:33:02 -0700 (PDT)
- Subject: Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r
- References: <201204271244.11035.toscano.pino@tiscali.it><20120427222101.E09882C0A2@topped-with-meat.com><201204281428.06845.toscano.pino@tiscali.it>
> Ok, I see that its `buf' argument is marked nonnull. I added that check
> because I saw the gnulib test for it explicitly checking that
> ptsname_r(fd, NULL, 0) would be properly failing with EINVAL (and the
> man page even explicitly mention that return value, unlike with
> basically most of the other functions). Should gnulib do that check only
> on Linux, then?
Well, everybody's wrong. The libc manual never said that you can pass NULL
and expect not to crash, and the man page was IMHO wrong to document it
that way. The other implementations never should have checked for NULL,
but they have done so for a long time. gnulib never should have passed
NULL to this function and IMHO it should be fixed not to do so.
But given the history, the least of avaialble evils is to make the Hurd
implementation consistent with the others and do the check.
Thanks,
Roland