[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r
From: |
Pino Toscano |
Subject: |
Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r |
Date: |
Mon, 19 Nov 2012 22:58:16 +0100 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; ) |
Hi,
Alle venerdì 20 luglio 2012, Roland McGrath ha scritto:
> > 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.
(few months later... I forgot I sent this patch, so I'm bring it again.)
I updated the patch; is it okay to commit, or should I bring back the
buf==NULL check?
--
Pino Toscano
hurd_ptsname.diff
Description: Text Data
signature.asc
Description: This is a digitally signed message part.
- Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r,
Pino Toscano <=