Remove __warn_memset_zero_len [bz #25399]

  Non-gcc compilers (clang and possibly other compilers that do not
masquerade as gcc 5.0 or later) are unable to use
__warn_memset_zero_len since the symbol is no longer available on
glibc built with gcc 5.0 or later.  While it was likely an oversight
that caused this omission, the fact that it wasn't noticed until
recently (when clang closed the gap on _FORTIFY_SUPPORT) that the
symbol was missing.

Given that both gcc and clang are capable of doing this check in the
compiler, drop all signs of __warn_memset_zero_len from glibc.

The __warndecl macro remains in there unused in the event that we need
it to add a similar check in future.
---
 string/bits/string_fortified.h | 15 ---------------
 1 file changed, 15 deletions(-)
  

* Siddhesh Poyarekar:

> Non-gcc compilers (clang and possibly other compilers that do not
> masquerade as gcc 5.0 or later) are unable to use
> __warn_memset_zero_len since the symbol is no longer available on
> glibc built with gcc 5.0 or later.  While it was likely an oversight
> that caused this omission, the fact that it wasn't noticed until
> recently (when clang closed the gap on _FORTIFY_SUPPORT) that the
> symbol was missing.
>
> Given that both gcc and clang are capable of doing this check in the
> compiler, drop all signs of __warn_memset_zero_len from glibc.
>
> The __warndecl macro remains in there unused in the event that we need
> it to add a similar check in future.

Nit: We tend to write: [BZ #25399]
(But the Git update hook does not react to the commit subject these days.)

Patch looks good.  Please remove the last paragraph of the commit
message and send a separate patch to remove __warndecl. 8-)

Thanks,
FLorian
  

On Wed, Nov 04, 2020 at 10:19:25AM +0100, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
> > Non-gcc compilers (clang and possibly other compilers that do not
> > masquerade as gcc 5.0 or later) are unable to use
> > __warn_memset_zero_len since the symbol is no longer available on
> > glibc built with gcc 5.0 or later.  While it was likely an oversight
> > that caused this omission, the fact that it wasn't noticed until
> > recently (when clang closed the gap on _FORTIFY_SUPPORT) that the
> > symbol was missing.
> >
> > Given that both gcc and clang are capable of doing this check in the
> > compiler, drop all signs of __warn_memset_zero_len from glibc.
> >
> > The __warndecl macro remains in there unused in the event that we need
> > it to add a similar check in future.
> 
> Nit: We tend to write: [BZ #25399]
> (But the Git update hook does not react to the commit subject these days.)
> 
> Patch looks good.  Please remove the last paragraph of the commit
> message and send a separate patch to remove __warndecl. 8-)

I think it can't be really removed.
It is ok if it doesn't warn anymore, and it is ok if it is not in the
headers anymore, but one can still have object files or *.a libraries compiled with
gcc 4.9 and earlier against older glibc and that will now fail to link
altogether.

	Jakub
  

* Jakub Jelinek:

> It is ok if it doesn't warn anymore, and it is ok if it is not in the
> headers anymore, but one can still have object files or *.a libraries
> compiled with gcc 4.9 and earlier against older glibc and that will
> now fail to link altogether.

In general, that is not supported.  We have recently made an exception
for __xstat.  But in this case, linking after removal will only fail if
there was an annoying linker warning before, so I think it's going to be
very rare that this makes a difference.

Thanks,
Florian
  

On 11/4/20 3:10 PM, Florian Weimer via Libc-alpha wrote:
> * Jakub Jelinek:
> 
>> It is ok if it doesn't warn anymore, and it is ok if it is not in the
>> headers anymore, but one can still have object files or *.a libraries
>> compiled with gcc 4.9 and earlier against older glibc and that will
>> now fail to link altogether.
> 
> In general, that is not supported.  We have recently made an exception
> for __xstat.  But in this case, linking after removal will only fail if
> there was an annoying linker warning before, so I think it's going to be
> very rare that this makes a difference.

I suppose another way to look at this is that the patch does not fix the 
link failure, it only ensures that the symbol doesn't appear in the 
future by accident.

We can then look at fixing the link failure by adding the symbol in if 
someone actually cares enough to file another bug.  Does that sound 
reasonable?

Siddhesh
  

* Siddhesh Poyarekar:

> On 11/4/20 3:10 PM, Florian Weimer via Libc-alpha wrote:
>> * Jakub Jelinek:
>> 
>>> It is ok if it doesn't warn anymore, and it is ok if it is not in the
>>> headers anymore, but one can still have object files or *.a libraries
>>> compiled with gcc 4.9 and earlier against older glibc and that will
>>> now fail to link altogether.
>> In general, that is not supported.  We have recently made an
>> exception
>> for __xstat.  But in this case, linking after removal will only fail if
>> there was an annoying linker warning before, so I think it's going to be
>> very rare that this makes a difference.
>
> I suppose another way to look at this is that the patch does not fix
> the link failure, it only ensures that the symbol doesn't appear in
> the future by accident.
>
> We can then look at fixing the link failure by adding the symbol in if
> someone actually cares enough to file another bug.  Does that sound 
> reasonable?

Eh, right.  The __warn_memset_zero_len symbol is currently not part of
libc_nonshared.a.  (Our downstream build of 2.17 still has it, but the
one based on 2.28 does not, due to a different GCC version being used.)
So there is no new backwards compatibility impact from remove the
__warndecl stuff.

Thanks,
Florian
  

On 11/4/20 3:26 PM, Florian Weimer via Libc-alpha wrote:
> Eh, right.  The __warn_memset_zero_len symbol is currently not part of
> libc_nonshared.a.  (Our downstream build of 2.17 still has it, but the
> one based on 2.28 does not, due to a different GCC version being used.)
> So there is no new backwards compatibility impact from remove the
> __warndecl stuff.

I have pushed this now.

Siddhesh