more out of bounds checking improvements

  The attached patch continues the improvements to out of bounds
checking(*) by decorating more APIs with either attribute access,
or by explicitly providing the array bound in APIs such as
tmpnam() that expect arrays of some minimum size as arguments.
(The latter feature is new in GCC 11.)

The only effects of the attribute and/or the array bound is to
check and diagnose calls to the functions that fail to provide
a sufficient number of elements, and the definitions of
the functions that access elements outside the specified bounds.
(There is no interplay with _FORTIFY_SOURCE here yet.)

For example, because the patch specifies the bound in the tmpnam
declaration like so:

    extern char *tmpnam (char[L_tmpnam]) __THROW __wur;

the following call to the function:

    char* warn_tmpnam (void)
    {
      char a[16];
      return tmpnam (a);
    }

triggers the warning below:

t.c: In function ‘warn_tmpnam’:
t.c:8:10: warning: ‘tmpnam’ accessing 20 bytes in a region of size 16 
[-Wstringop-overflow=]
      8 |   return tmpnam (a);
        |          ^~~~~~~~~~
t.c:8:10: note: referencing argument 1 of type ‘char *’
In file included from ../include/stdio.h:14,
                   from test-access-warn.c:1:
../libio/stdio.h:187:14: note: in a call to function ‘tmpnam’
    187 | extern char *tmpnam (char[L_tmpnam]) __THROW __wur;
        |              ^~~~~~

Unlike the [static N] notation, the plain array notation doesn't
require the argument to be nonnull.

Besides attribute access, the change adds attribute nonnull to
the readv and writev functions in misc/sys/uio.h.  The functions
don't necessarily access the array elements when their count is
zero but neither POSIX nor the Linux manual document this so it
seems appropriate to warn.

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
my way out of the maze of scripts and makefiles that tie all this
together.

Thanks
Martin

[*] https://sourceware.org/pipermail/libc-alpha/2020-April/113503.html
  

* Martin Sebor via Libc-alpha:

> Besides attribute access, the change adds attribute nonnull to
> the readv and writev functions in misc/sys/uio.h.  The functions
> don't necessarily access the array elements when their count is
> zero but neither POSIX nor the Linux manual document this so it
> seems appropriate to warn.

This change is questionable because it breaks interoperability with
abstract data types such as std::vector, where the base pointer can be
null when the array is empty.  The kernel does not return EFAULT in this
case, as expected.

I think we need a special case for this.

Thanks,
Florian
  

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).
  

On 10/26/20 9:41 AM, Florian Weimer wrote:
> * Martin Sebor via Libc-alpha:
> 
>> Besides attribute access, the change adds attribute nonnull to
>> the readv and writev functions in misc/sys/uio.h.  The functions
>> don't necessarily access the array elements when their count is
>> zero but neither POSIX nor the Linux manual document this so it
>> seems appropriate to warn.
> 
> This change is questionable because it breaks interoperability with
> abstract data types such as std::vector, where the base pointer can be
> null when the array is empty.  The kernel does not return EFAULT in this
> case, as expected.

Let me separate this out from the main patch if it isn't
straightforward.  Although POSIX doesn't require the functions to
fail, it does suggest, albeit obliquely, they may fail when the iov
pointer is null:

   The iovcnt argument is valid if greater than 0 and less than or
   equal to {IOV_MAX}, as defined in <limits.h>.

   The writev() function may fail and set errno to:

   [EINVAL]
     The iovcnt argument was less than or equal to 0, or greater than
     {IOV_MAX}.

Passing the functions a null iov pointer is only realistic when
iovcnt is zero.  The former is nonconforming and undefined under
any conditions (null isn't a valid argument to any library
function unless specified otherwise), and the latter may cause
the function to fail.  A warning for it seems to me both
appropriate and helpful, certainly in the absence of the Glibc
or Linux man pages documenting the behavior under these
conditions.

Martin

> I think we need a special case for this.
> 
> Thanks,
> Florian
>
  

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.
  

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.
  

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.
>
  

Ping: still looking for an approval of the patch below before
tomorrow's freeze:
https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html

On 1/4/21 8:54 AM, Martin Sebor wrote:
> 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.
>>
>
  

Florian reminded me that this patch (first posted on 10/26 last
year) is still outstanding so I'd like to try to ping it again.

Florian and Joseph provided some initial comments but not a formal
approval.

Martin

On 1/10/21 1:44 PM, Martin Sebor wrote:
> Ping: still looking for an approval of the patch below before
> tomorrow's freeze:
> https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html
> 
> On 1/4/21 8:54 AM, Martin Sebor wrote:
>> 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.
>>>
>>
>
  

* Martin Sebor via Libc-alpha:

> diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
> index e587a5ce59..30f3e281e5 100644
> --- a/sysdeps/gnu/net/if.h
> +++ b/sysdeps/gnu/net/if.h
> @@ -191,7 +191,9 @@ __BEGIN_DECLS
>  
>  /* Convert an interface name to an index, and vice versa.  */
>  extern unsigned int if_nametoindex (const char *__ifname) __THROW;
> -extern char *if_indextoname (unsigned int __ifindex, char *__ifname) __THROW;
> +extern char *if_indextoname (unsigned int __ifindex,
> +			     char __ifname[IF_NAMESIZE]) __THROW
> +    __attr_access ((__write_only__, 2));
>  
>  /* Return a list of all interfaces and their indices.  */
>  extern struct if_nameindex *if_nameindex (void) __THROW;

Is the change from a pointer to an array allowed by POSIX?

Thanks,
Florian
  

On 4/23/21 4:31 AM, Florian Weimer wrote:
> * Martin Sebor via Libc-alpha:
> 
>> diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
>> index e587a5ce59..30f3e281e5 100644
>> --- a/sysdeps/gnu/net/if.h
>> +++ b/sysdeps/gnu/net/if.h
>> @@ -191,7 +191,9 @@ __BEGIN_DECLS
>>   
>>   /* Convert an interface name to an index, and vice versa.  */
>>   extern unsigned int if_nametoindex (const char *__ifname) __THROW;
>> -extern char *if_indextoname (unsigned int __ifindex, char *__ifname) __THROW;
>> +extern char *if_indextoname (unsigned int __ifindex,
>> +			     char __ifname[IF_NAMESIZE]) __THROW
>> +    __attr_access ((__write_only__, 2));
>>   
>>   /* Return a list of all interfaces and their indices.  */
>>   extern struct if_nameindex *if_nameindex (void) __THROW;
> 
> Is the change from a pointer to an array allowed by POSIX?

There's no way for a conforming program to tell how a function pointer
parameter is declared so I believe it is.

Martin
  

* Martin Sebor:

> On 4/23/21 4:31 AM, Florian Weimer wrote:
>> * Martin Sebor via Libc-alpha:
>> 
>>> diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
>>> index e587a5ce59..30f3e281e5 100644
>>> --- a/sysdeps/gnu/net/if.h
>>> +++ b/sysdeps/gnu/net/if.h
>>> @@ -191,7 +191,9 @@ __BEGIN_DECLS
>>>     /* Convert an interface name to an index, and vice versa.  */
>>>   extern unsigned int if_nametoindex (const char *__ifname) __THROW;
>>> -extern char *if_indextoname (unsigned int __ifindex, char *__ifname) __THROW;
>>> +extern char *if_indextoname (unsigned int __ifindex,
>>> +			     char __ifname[IF_NAMESIZE]) __THROW
>>> +    __attr_access ((__write_only__, 2));
>>>     /* Return a list of all interfaces and their indices.  */
>>>   extern struct if_nameindex *if_nameindex (void) __THROW;
>> Is the change from a pointer to an array allowed by POSIX?
>
> There's no way for a conforming program to tell how a function pointer
> parameter is declared so I believe it is.

Hmm, I think you might be right.  It's like parameter names in this
regard.

Thanks,
Florian
  

On 4/23/21 10:01 AM, Florian Weimer wrote:
> * Martin Sebor:
> 
>> On 4/23/21 4:31 AM, Florian Weimer wrote:
>>> * Martin Sebor via Libc-alpha:
>>>
>>>> diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
>>>> index e587a5ce59..30f3e281e5 100644
>>>> --- a/sysdeps/gnu/net/if.h
>>>> +++ b/sysdeps/gnu/net/if.h
>>>> @@ -191,7 +191,9 @@ __BEGIN_DECLS
>>>>      /* Convert an interface name to an index, and vice versa.  */
>>>>    extern unsigned int if_nametoindex (const char *__ifname) __THROW;
>>>> -extern char *if_indextoname (unsigned int __ifindex, char *__ifname) __THROW;
>>>> +extern char *if_indextoname (unsigned int __ifindex,
>>>> +			     char __ifname[IF_NAMESIZE]) __THROW
>>>> +    __attr_access ((__write_only__, 2));
>>>>      /* Return a list of all interfaces and their indices.  */
>>>>    extern struct if_nameindex *if_nameindex (void) __THROW;
>>> Is the change from a pointer to an array allowed by POSIX?
>>
>> There's no way for a conforming program to tell how a function pointer
>> parameter is declared so I believe it is.
> 
> Hmm, I think you might be right.  It's like parameter names in this
> regard.

You sound disappointed ;)

If there are no further comments/concerns I'll retest the patch on top
of the latest trunk and if all goes well go ahead with the commit later
this week.

Martin

> 
> Thanks,
> Florian
>
  

On 5/4/21 1:58 PM, Martin Sebor wrote:
> On 4/23/21 10:01 AM, Florian Weimer wrote:
>> * Martin Sebor:
>>
>>> On 4/23/21 4:31 AM, Florian Weimer wrote:
>>>> * Martin Sebor via Libc-alpha:
>>>>
>>>>> diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
>>>>> index e587a5ce59..30f3e281e5 100644
>>>>> --- a/sysdeps/gnu/net/if.h
>>>>> +++ b/sysdeps/gnu/net/if.h
>>>>> @@ -191,7 +191,9 @@ __BEGIN_DECLS
>>>>>      /* Convert an interface name to an index, and vice versa.  */
>>>>>    extern unsigned int if_nametoindex (const char *__ifname) __THROW;
>>>>> -extern char *if_indextoname (unsigned int __ifindex, char 
>>>>> *__ifname) __THROW;
>>>>> +extern char *if_indextoname (unsigned int __ifindex,
>>>>> +                 char __ifname[IF_NAMESIZE]) __THROW
>>>>> +    __attr_access ((__write_only__, 2));
>>>>>      /* Return a list of all interfaces and their indices.  */
>>>>>    extern struct if_nameindex *if_nameindex (void) __THROW;
>>>> Is the change from a pointer to an array allowed by POSIX?
>>>
>>> There's no way for a conforming program to tell how a function pointer
>>> parameter is declared so I believe it is.
>>
>> Hmm, I think you might be right.  It's like parameter names in this
>> regard.
> 
> You sound disappointed ;)
> 
> If there are no further comments/concerns I'll retest the patch on top
> of the latest trunk and if all goes well go ahead with the commit later
> this week.

Retesting the changes with GCC 7 through 11 exposed a few minor bugs
in Glibc tests and a possible false positive for makedb.c with GCC 10.
I have fixed those and committed the attached patch in g:26492c0a14.

Martin
  

On Thu, 6 May 2021, Martin Sebor via Libc-alpha wrote:

> @@ -171,7 +172,18 @@ do_test (void)
>       allocation.  */
>    fails |= test_wrp2 (LIST (EINVAL, ENOMEM), mlock, (void *) -1, 1);
>    fails |= test_wrp (EINVAL, nanosleep, &ts, &ts);
> +
> +  DIAG_POP_NEEDS_COMMENT;
> +
> +#if __GNUC_PREREQ (9, 0)
> +  /* Suppress valid GCC warning:
> +     'poll' specified size 18446744073709551608 exceeds maximum object size
> +  */
> +  DIAG_IGNORE_NEEDS_COMMENT (9, "-Wstringop-overflow=");
> +#endif
>    fails |= test_wrp (EINVAL, poll, &pollfd, -1, 0);
> +  DIAG_POP_NEEDS_COMMENT;

The first DIAG_POP_NEEDS_COMMENT looks like it should be 
DIAG_PUSH_NEEDS_COMMENT.
  

On 5/6/21 12:15 PM, Joseph Myers wrote:
> On Thu, 6 May 2021, Martin Sebor via Libc-alpha wrote:
> 
>> @@ -171,7 +172,18 @@ do_test (void)
>>        allocation.  */
>>     fails |= test_wrp2 (LIST (EINVAL, ENOMEM), mlock, (void *) -1, 1);
>>     fails |= test_wrp (EINVAL, nanosleep, &ts, &ts);
>> +
>> +  DIAG_POP_NEEDS_COMMENT;
>> +
>> +#if __GNUC_PREREQ (9, 0)
>> +  /* Suppress valid GCC warning:
>> +     'poll' specified size 18446744073709551608 exceeds maximum object size
>> +  */
>> +  DIAG_IGNORE_NEEDS_COMMENT (9, "-Wstringop-overflow=");
>> +#endif
>>     fails |= test_wrp (EINVAL, poll, &pollfd, -1, 0);
>> +  DIAG_POP_NEEDS_COMMENT;
> 
> The first DIAG_POP_NEEDS_COMMENT looks like it should be
> DIAG_PUSH_NEEDS_COMMENT.
> 

Fixed!  Thanks for double-checking the final patch!

Martin
  

makedb.c: In function 'write_output':
makedb.c:797:7: error: 'writev' specified size 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
  797 |   if (writev (fd, iov, iov_nelts) != keydataoffset)
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/sys/uio.h:2,
                 from makedb.c:39:
../misc/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)'
   52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count)
      |                ^~~~~~
cc1: all warnings being treated as errors
make[2]: *** [../o-iterator.mk:9: /home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/cc-base/nss/makedb.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/nss'
make[1]: *** [Makefile:479: nss/others] Error 2
make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd'
make: *** [Makefile:9: all] Error 2

Andreas.
  

* Andreas Schwab:

> makedb.c: In function 'write_output':
> makedb.c:797:7: error: 'writev' specified size 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
>   797 |   if (writev (fd, iov, iov_nelts) != keydataoffset)
>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from ../include/sys/uio.h:2,
>                  from makedb.c:39:
> ../misc/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)'
>    52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count)
>       |                ^~~~~~
> cc1: all warnings being treated as errors
> make[2]: *** [../o-iterator.mk:9: /home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/cc-base/nss/makedb.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/nss'
> make[1]: *** [Makefile:479: nss/others] Error 2
> make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd'
> make: *** [Makefile:9: all] Error 2

Are you building with -DNDEBUG?

Yes, the assert approach will not work in that case.

Thanks,
Florian
  

On Mai 07 2021, Florian Weimer wrote:

> Are you building with -DNDEBUG?

No.

Andreas.
  

Andreas Schwab <schwab@linux-m68k.org> writes:

> makedb.c: In function 'write_output':
> makedb.c:797:7: error: 'writev' specified size 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
>   797 |   if (writev (fd, iov, iov_nelts) != keydataoffset)
>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from ../include/sys/uio.h:2,
>                  from makedb.c:39:
> ../misc/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)'
>    52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count)
>       |                ^~~~~~
> cc1: all warnings being treated as errors
> make[2]: *** [../o-iterator.mk:9: /home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/cc-base/nss/makedb.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd/nss'
> make[1]: *** [Makefile:479: nss/others] Error 2
> make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/glibc-2.33.9000.515.g3bf0b4f2cd'
> make: *** [Makefile:9: all] Error 2

I'm also reproducing this on ppc32 with GCC 10.
I'm not using -DNDEBUG.
  

* Martin Sebor via Libc-alpha:

> diff --git a/nss/makedb.c b/nss/makedb.c
> index 74edb749cf..9389f6b548 100644
> --- a/nss/makedb.c
> +++ b/nss/makedb.c
> @@ -747,7 +747,8 @@ write_output (int fd)
>    header->valstrlen = valstrlen;
>  
>    size_t filled_dbs = 0;
> -  struct iovec iov[2 + ndatabases * 3];
> +  size_t iov_nelts = 2 + ndatabases * 3;
> +  struct iovec iov[iov_nelts];
>    iov[0].iov_base = header;
>    iov[0].iov_len = file_offset;
>  
> @@ -791,7 +792,9 @@ write_output (int fd)
>  			  + nhashentries_total * sizeof (stridx_t)));
>    header->allocate = file_offset;
>  
> -  if (writev (fd, iov, 2 + ndatabases * 3) != keydataoffset)
> +  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
> +  assert (iov_nelts <= INT_MAX);
> +  if (writev (fd, iov, iov_nelts) != keydataoffset)
>      {
>        error (0, errno, gettext ("failed to write new database file"));
>        return EXIT_FAILURE;

I don't think you should use assert to suppress compiler warnings
because we are supposed to have warning-free builds even with -DNDEBUG
(although it's likely that other problems exist).

Thanks,
Florian
  

On 5/10/21 2:45 AM, Florian Weimer wrote:
> * Martin Sebor via Libc-alpha:
> 
>> diff --git a/nss/makedb.c b/nss/makedb.c
>> index 74edb749cf..9389f6b548 100644
>> --- a/nss/makedb.c
>> +++ b/nss/makedb.c
>> @@ -747,7 +747,8 @@ write_output (int fd)
>>     header->valstrlen = valstrlen;
>>   
>>     size_t filled_dbs = 0;
>> -  struct iovec iov[2 + ndatabases * 3];
>> +  size_t iov_nelts = 2 + ndatabases * 3;
>> +  struct iovec iov[iov_nelts];
>>     iov[0].iov_base = header;
>>     iov[0].iov_len = file_offset;
>>   
>> @@ -791,7 +792,9 @@ write_output (int fd)
>>   			  + nhashentries_total * sizeof (stridx_t)));
>>     header->allocate = file_offset;
>>   
>> -  if (writev (fd, iov, 2 + ndatabases * 3) != keydataoffset)
>> +  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
>> +  assert (iov_nelts <= INT_MAX);
>> +  if (writev (fd, iov, iov_nelts) != keydataoffset)
>>       {
>>         error (0, errno, gettext ("failed to write new database file"));
>>         return EXIT_FAILURE;
> 
> I don't think you should use assert to suppress compiler warnings
> because we are supposed to have warning-free builds even with -DNDEBUG
> (although it's likely that other problems exist).

So how about the following instead of the assert?

diff --git a/nss/makedb.c b/nss/makedb.c
index 9389f6b548..6551b3cf2a 100644
--- a/nss/makedb.c
+++ b/nss/makedb.c
@@ -792,14 +792,25 @@ write_output (int fd)
                           + nhashentries_total * sizeof (stridx_t)));
    header->allocate = file_offset;

-  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
    assert (iov_nelts <= INT_MAX);
+
+#if __GNUC_PREREQ (10, 0)
+  DIAG_PUSH_NEEDS_COMMENT;
+  /* Avoid GCC 10 false positice warning: specified size exceeds maximum
+     object size.  */
+  DIAG_IGNORE_NEEDS_COMMENT (10, "-Wstringop-overflow");
+#endif
+
    if (writev (fd, iov, iov_nelts) != keydataoffset)
      {
        error (0, errno, gettext ("failed to write new database file"));
        return EXIT_FAILURE;
      }

+#if __GNUC_PREREQ (10, 0)
+  DIAG_POP_NEEDS_COMMENT;
+#endif
+
    return EXIT_SUCCESS;
  }

Martin
  

On Fri, 7 May 2021, Tulio Magno Quites Machado Filho via Libc-alpha wrote:

> I'm also reproducing this on ppc32 with GCC 10.
> I'm not using -DNDEBUG.

It looks like this appears for all 32-bit platforms with GCC 10 (but not 
GCC 11, or for 64-bit platforms).

https://sourceware.org/pipermail/libc-testresults/2021q2/007905.html
  

* Martin Sebor:

> diff --git a/nss/makedb.c b/nss/makedb.c
> index 9389f6b548..6551b3cf2a 100644
> --- a/nss/makedb.c
> +++ b/nss/makedb.c
> @@ -792,14 +792,25 @@ write_output (int fd)
>                           + nhashentries_total * sizeof (stridx_t)));
>    header->allocate = file_offset;
>
> -  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
>    assert (iov_nelts <= INT_MAX);
> +
> +#if __GNUC_PREREQ (10, 0)
> +  DIAG_PUSH_NEEDS_COMMENT;
> +  /* Avoid GCC 10 false positice warning: specified size exceeds maximum
> +     object size.  */
> +  DIAG_IGNORE_NEEDS_COMMENT (10, "-Wstringop-overflow");
> +#endif
> +
>    if (writev (fd, iov, iov_nelts) != keydataoffset)
>      {
>        error (0, errno, gettext ("failed to write new database file"));
>        return EXIT_FAILURE;
>      }
>
> +#if __GNUC_PREREQ (10, 0)
> +  DIAG_POP_NEEDS_COMMENT;
> +#endif
> +
>    return EXIT_SUCCESS;
>  }

Typo: positice

I'm building this with build-many-glibcs.py right now, first with GCC
11, then with GCC 10.  I don't have a GCC 10 tree yet, so it's goint to
take some time, hopefully less than two hours.

If the warning happens with GCC 10 only, should we disable it for GCC 11
as well?

Thanks,
Florian
  

On 5/10/21 11:49 AM, Florian Weimer wrote:
> * Martin Sebor:
> 
>> diff --git a/nss/makedb.c b/nss/makedb.c
>> index 9389f6b548..6551b3cf2a 100644
>> --- a/nss/makedb.c
>> +++ b/nss/makedb.c
>> @@ -792,14 +792,25 @@ write_output (int fd)
>>                            + nhashentries_total * sizeof (stridx_t)));
>>     header->allocate = file_offset;
>>
>> -  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
>>     assert (iov_nelts <= INT_MAX);
>> +
>> +#if __GNUC_PREREQ (10, 0)
>> +  DIAG_PUSH_NEEDS_COMMENT;
>> +  /* Avoid GCC 10 false positice warning: specified size exceeds maximum
>> +     object size.  */
>> +  DIAG_IGNORE_NEEDS_COMMENT (10, "-Wstringop-overflow");
>> +#endif
>> +
>>     if (writev (fd, iov, iov_nelts) != keydataoffset)
>>       {
>>         error (0, errno, gettext ("failed to write new database file"));
>>         return EXIT_FAILURE;
>>       }
>>
>> +#if __GNUC_PREREQ (10, 0)
>> +  DIAG_POP_NEEDS_COMMENT;
>> +#endif
>> +
>>     return EXIT_SUCCESS;
>>   }
> 
> Typo: positice
> 
> I'm building this with build-many-glibcs.py right now, first with GCC
> 11, then with GCC 10.  I don't have a GCC 10 tree yet, so it's goint to
> take some time, hopefully less than two hours.
> 
> If the warning happens with GCC 10 only, should we disable it for GCC 11
> as well?

It doesn't need to be disabled for GCC 11 but I don't know how to
be this selective with these version macros.  If it's okay to use
__GNUC__ then this works:

index 9389f6b548..6a061e6457 100644
--- a/nss/makedb.c
+++ b/nss/makedb.c
@@ -792,7 +792,15 @@ write_output (int fd)
                           + nhashentries_total * sizeof (stridx_t)));
    header->allocate = file_offset;

-  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
+  assert (iov_nelts <= INT_MAX);
+
+#if __GNUC__ == 10
+  DIAG_PUSH_NEEDS_COMMENT;
+  /* Avoid GCC 10 false positive warning: specified size exceeds maximum
+     object size.  */
+  DIAG_IGNORE_NEEDS_COMMENT (10, "-Wstringop-overflow");
+#endif
+
    assert (iov_nelts <= INT_MAX);
    if (writev (fd, iov, iov_nelts) != keydataoffset)
      {
@@ -800,6 +808,10 @@ write_output (int fd)
        return EXIT_FAILURE;
      }

+#if __GNUC__ == 10
+  DIAG_POP_NEEDS_COMMENT;
+#endif
+
    return EXIT_SUCCESS;
  }

Martin

> 
> Thanks,
> Florian
>
  

On Mai 10 2021, Martin Sebor via Libc-alpha wrote:

> It doesn't need to be disabled for GCC 11 but I don't know how to
> be this selective with these version macros.  If it's okay to use
> __GNUC__ then this works:
>
> index 9389f6b548..6a061e6457 100644
> --- a/nss/makedb.c
> +++ b/nss/makedb.c
> @@ -792,7 +792,15 @@ write_output (int fd)
>                           + nhashentries_total * sizeof (stridx_t)));
>    header->allocate = file_offset;
>
> -  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
> +  assert (iov_nelts <= INT_MAX);
> +
> +#if __GNUC__ == 10

You can use __GNUC_PREREQ (10, 0) && !__GNUC_PREREQ (11, 0)

Andreas.
  

* Andreas Schwab:

> On Mai 10 2021, Martin Sebor via Libc-alpha wrote:
>
>> It doesn't need to be disabled for GCC 11 but I don't know how to
>> be this selective with these version macros.  If it's okay to use
>> __GNUC__ then this works:
>>
>> index 9389f6b548..6a061e6457 100644
>> --- a/nss/makedb.c
>> +++ b/nss/makedb.c
>> @@ -792,7 +792,15 @@ write_output (int fd)
>>                           + nhashentries_total * sizeof (stridx_t)));
>>    header->allocate = file_offset;
>>
>> -  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
>> +  assert (iov_nelts <= INT_MAX);
>> +
>> +#if __GNUC__ == 10
>
> You can use __GNUC_PREREQ (10, 0) && !__GNUC_PREREQ (11, 0)

That works for me too.

I've tested the previous version (partially quoted above) with GCC 11
and GCC 10, and it builds.

It's too late for me to test Andreas' proposal today, but I think it
should be safe to push it.  I can retest it tomorrow with GCC 9/10/11,
just to be sure.

Thanks,
Florian
  

On 5/10/21 1:50 PM, Florian Weimer wrote:
> * Andreas Schwab:
> 
>> On Mai 10 2021, Martin Sebor via Libc-alpha wrote:
>>
>>> It doesn't need to be disabled for GCC 11 but I don't know how to
>>> be this selective with these version macros.  If it's okay to use
>>> __GNUC__ then this works:
>>>
>>> index 9389f6b548..6a061e6457 100644
>>> --- a/nss/makedb.c
>>> +++ b/nss/makedb.c
>>> @@ -792,7 +792,15 @@ write_output (int fd)
>>>                            + nhashentries_total * sizeof (stridx_t)));
>>>     header->allocate = file_offset;
>>>
>>> -  /* Help GCC 10 see iov_nelts doesn't overflow the writev argument.  */
>>> +  assert (iov_nelts <= INT_MAX);
>>> +
>>> +#if __GNUC__ == 10
>>
>> You can use __GNUC_PREREQ (10, 0) && !__GNUC_PREREQ (11, 0)
> 
> That works for me too.
> 
> I've tested the previous version (partially quoted above) with GCC 11
> and GCC 10, and it builds.
> 
> It's too late for me to test Andreas' proposal today, but I think it
> should be safe to push it.  I can retest it tomorrow with GCC 9/10/11,
> just to be sure.

I have pushed the change.

Martin
  

* Martin Sebor:

> I have pushed the change.

Thanks, my build tests didn't show any issues.

Florian