Ping: [PATCH] more out of bounds checking improvements

[Martin Sebor]

Ping: Does the last patch look good enough to commit?
https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html

On 12/9/20 2:46 PM, Martin Sebor wrote:
> On 10/26/20 10:08 AM, Joseph Myers wrote:
>> On Mon, 26 Oct 2020, Martin Sebor via Libc-alpha wrote:
>>
>>> The patch introduces the _L_tmpnam macro to avoid polluting
>>> the POSIX <unistd.h> namespace with L_tmpnam when the latter is
>>> only supposed to be defined in <stdio.h>.  This in turn causes
>>> the a number of POSIX conformance test failures that I haven't
>>> been able to figure how to deal with and need some help with.
>>>
>>> In file included from ../include/unistd.h:2,
>>>                   from /tmp/tmpzm39v4n3/test.c:1:
>>> ../posix/unistd.h:1159:32: error: ‘_L_ctermid’ undeclared here (not in a
>>> function)
>>>   extern char *ctermid (char __s[_L_ctermid]) __THROW
>>>                                  ^~~~~~~~~~
>>>
>>> I expected adding the new macros to stdio-common/stdio_lim.h.in
>>> would do the trick but clearly something else is needed and I'm
>>> at a lost as to what that might be.  I haven't been able to find
>>
>> <unistd.h> doesn't include <bits/stdio_lim.h>, and you're making
>> <unistd.h> use _L_ctermid, and you're only defining _L_ctermid in
>> <bits/stdio_lim.h>.  You need to define it in a header that <unistd.h>
>> includes - which also needs to be one whose contents are namespace-clean
>> for inclusion in <unistd.h> (which <bits/stdio_lim.h> isn't).
>>
>> The obvious way would be to have a new installed (i.e. add to 
>> "headers" in
>> the relevant Makefile) header for the new macros that can be included in
>> both <stdio.h> and <unistd.h>.  Suggestion: the existing scheme for
>> automatic generation of bits/stdio_lim.h is overly complicated, it would
>> be better to use sysdeps headers in the normal way like for other bits/
>> headers where the values may depend on the glibc configuration (and then
>> to have testcases that verify consistently of OPEN_MAX and FOPEN_MAX / of
>> PATH_MAX and FILENAME_MAX, when both are defined).
> 
> I don't know enough about the Glibc build infrastructure to
> understand your suggestion but either approach sounds more involved
> than I have cycles for so I propose the scaled patch instead, without
> the ctermid and cuserid changes (and without the nonnull attribute
> on readv/writev(*)).  Hopefully someone with more experience with
> the existing scheme will find a way to define the two macros and
> make use of them to enable the detection for these two functions
> as well.
> 
> Martin
> 
> [*] I'll submit that patch separately.