strlen optimizations based on whether stpcpy is declared?

[Jakub Jelinek]

On Mon, Oct 02, 2017 at 10:41:59AM -0600, Martin Sebor wrote:
> I also take back what I said about application programs being
> unaffected by this.  Using the declaration to make these decisions
> results in less optimal code when compiling in strict conformance
> mode (e.g., -std=c11 or -std=c++14) than in "relaxed mode" (-std=
> gnu11 or -std=gnu++14).  This can be seen using the following test
> case:

Only for C, and even for -std=c99 or -std=c11 one can use -D_GNU_SOURCE
or -D_POSIX_C_SOURCE=200809 or -D_XOPEN_SOURCE=700 and various others
to make stpcpy available.  For C++ we define _GNU_SOURCE (unfortunately)
unconditionally.

>   #include <string.h>
> 
>   void f (char *d, const char *s)
>   {
>     strcpy (d, s);
> 
>     if (__builtin_strlen (d) != __builtin_strlen (s))
>        __builtin_abort ();
>   }
> 
> I understand this is because, as you said, in strict mode, stpcpy
> could be declared to be a different symbol.  After our discussion
> I will (hopefully) remember this and avoid getting surprised by
> it in the future.  But it still feels like a subtlety that should
> be more prominently advertised somehow/somewhere to help others
> avoid falling into the same trap.

Why should it be advertised?  It is an optimization.  We use it when
we feel it is safe to do so.  It isn't something that should be documented
in user manuals IMNSHO.

	Jakub