On 9/27/19 1:06 PM, Martin Sebor wrote:
> GCC declares bcmp, bcopy, and bzero without the nonnull attribute.
> This was a deliberate decision as is reflected in the comment in
> builtins.def:
> 
> /* bcmp, bcopy and bzero have traditionally accepted NULL pointers
>    when the length parameter is zero, so don't apply attribute
> "nonnull".  */
> 
> But the SUSv3, Issue 6 marks the functions as legacy and recommends
> portable applications to replace calls to the functions with the C
> standard equivalents as follows:
> 
>   #define bcmp(b1,b2,len) memcmp((b1), (b2), (size_t)(len))
> 
> (The legacy functions have been removed from POSIX in Issue 7.)
> 
> The C standard functions do require their arguments to be nonnull.
> 
> Some libcs (e.g., Glibc) implement the legacy functions in terms
> of the C standard equivalents.  Others (e.g., libiberty) rely on
> strictly undefined behavior in their implementation of these
> function (null pointer arithmetic).
> 
> Finally, GCC has been transforming calls to the legacy functions
> to the C standard equivalents for a few releases, and making
> the same assumptions about their arguments (i.e., eliminating
> tests for their pointer arguments being null subsequent to
> the calls).
> 
> To help detect some of the same mistakes in calls to the legacy
> functions as in the standard ones the attached adds the nonnull
> attribute to all three of them.
> 
> Tested on x86_64-linux.  Compiling Binutils/GDB and Glibc with
> the patch doesn't turn up any -Wnonnull instances.
> 
> Martin
> 
> gcc-80936.diff
> 
> PR tree-optimization/80936 - bcmp, bcopy, and bzero not declared nonnull
> 
> gcc/testsuite/ChangeLog:
> 
>       PR tree-optimization/80936
>       * gcc.dg/Wnonnull-2.c: New test.
>       * gcc.dg/Wnonnull-3.c: New test.
>       * gcc.dg/nonnull-3.c: Expect more warnings.
> 
> gcc/ChangeLog:
> 
>       PR tree-optimization/80936
>       * builtins.def (bcmp, bcopy, bzero): Declare nonnull.
OK.  I'll be doing another Fedora rebuild relatively soon, so we'll have
a chance to see if there's fallout on a wider codebase.  I don't expect
significant issues.

jeff

Reply via email to