https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89748
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com,
| |fw at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, this is a glibc bug.
#ifdef __USE_XOPEN2K8
/* Return a string describing the meaning of the signal number in SIG. */
extern char *strsignal (int __sig) __THROW;
/* Copy SRC to DEST, returning the address of the terminating '\0' in DEST. */
extern char *__stpcpy (char *__restrict __dest, const char *__restrict __src)
__THROW __nonnull ((1, 2));
extern char *stpcpy (char *__restrict __dest, const char *__restrict __src)
__THROW __nonnull ((1, 2));
/* Copy no more than N characters of SRC to DEST, returning the address of
the last character written into DEST. */
extern char *__stpncpy (char *__restrict __dest,
const char *__restrict __src, size_t __n)
__THROW __nonnull ((1, 2));
extern char *stpncpy (char *__restrict __dest,
const char *__restrict __src, size_t __n)
__THROW __nonnull ((1, 2));
#endif
vs.
#ifdef __USE_GNU
__fortify_function char *
__NTH (stpcpy (char *__restrict __dest, const char *__restrict __src))
{
return __builtin___stpcpy_chk (__dest, __src, __bos (__dest));
}
#endif
On the other side, the stpncpy fortification wrapper is not guarded with any
feature test macro, but stpncpy prototype is.
https://sourceware.org/git/?p=glibc.git;a=commit;f=string/string.h;h=6cbe890a9d379d85fe849a8317010f05ace00809
has not updated the bits/string3.h header (what is now string_fortified.h).
I guess somebody needs to verify all the fortification wrappers and compare
their guarding macros (if any) against those in the normal headers.
