Ping 2: [PATCH] more out of bounds checking improvements

[Martin Sebor <msebor@gmail.com>]

Joseph or anyone else: is the patch below okay to commit?  I'd like
to include it in the upcoming release.

https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html

On 12/18/20 9:56 AM, Martin Sebor wrote:
> 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.
>