On 10/02/2017 12:00 PM, Jakub Jelinek wrote:
On Mon, Oct 02, 2017 at 11:45:24AM -0600, Martin Sebor wrote:
What's more, in strict mode GCC transforms stpcpy calls to strcpy.
Only if the result is not needed or if the length of the source string
is already known. And we do that transformation regardless of strict
mode. If the result is needed, I don't believe
we ever do that, it would be a clear opposite of optimization,
replace one call that does both the copying and computing the length
(well, end address, but that is simple pointer arithmetics away from that)
to computing the length one way and copying another way.
I see. Okay, that explains that.
What about the part about:
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.
It's not what happens. But what does seem to do it is when, in
addition to defining one of the macros, stpcpy is also explicitly
declared in the program, like so:
#include <string.h>
extern char* stpcpy (char*, const char*);
void __attribute__ ((noclone)) f (char *d, const char *s)
{
strcpy (d, s);
if (__builtin_strlen (d) != __builtin_strlen (s))
__builtin_abort ();
}
Then the strcpy is transformed into stpcpy. That seems odd and
like a bug, do you agree?
This is different for mempcpy where the result can be computed quite cheaply
and thus what kind of builtin is used doesn't matter that much, only that
we shouldn't introduce a less standard call when more standard one was used
in the source.
This makes sense as a rule of thumb. The strcpy to stpcpy
transformation is less intuitive and, if it has consensus,
I think would a good example of the acceptable tradeoffs that
would be helpful for GCC developers without the benefit of all
the past discussions and decisions to be aware of.
Martin
