[PATCH v2] Replace __strcpy_chk with __builtin___strcpy_chk

[H.J. Lu]

On Wed, Dec 18, 2024, 8:31 AM Siddhesh Poyarekar <siddhesh@gotplt.org>
wrote:

> On 2024-12-17 17:55, H.J. Lu wrote:
> > Although _chk functions are exported in libc.so.6, their prototypes
> aren't
> > provided.  Their built versions are supported by compiler.  Replace
> > __strcpy_chk with __builtin___strcpy_chk to silence Clang error:
> >
> > ./tst-gnuglob-skeleton.c:225:3: error: call to undeclared function
> '__strcpy_chk'; ISO C99 and later do not support implicit function
> declarations [-Wimplicit-function-declaration]
> >    225 |   __strcpy_chk (dir->d.d_name, filesystem[dir->idx].name,
> NAME_MAX);
> >        |   ^
> >
> > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> > ---
> >   posix/tst-glob_lstat_compat.c | 3 ++-
> >   posix/tst-gnuglob-skeleton.c  | 3 ++-
> >   2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/posix/tst-glob_lstat_compat.c
> b/posix/tst-glob_lstat_compat.c
> > index 6ea3b062f0..752a8c8707 100644
> > --- a/posix/tst-glob_lstat_compat.c
> > +++ b/posix/tst-glob_lstat_compat.c
> > @@ -173,7 +173,8 @@ my_readdir (void *gdir)
> >
> >     dir->d.d_type = filesystem[dir->idx].type;
> >
> > -  __strcpy_chk (dir->d.d_name, filesystem[dir->idx].name, NAME_MAX);
> > +  __builtin___strcpy_chk (dir->d.d_name, filesystem[dir->idx].name,
> > +                       NAME_MAX);
>
> So... __builtin___strcpy_chk is not strictly equivalent to __strcpy_chk;
> sorry I should have pointed that out when Sam mentioned it.
> __builtin___strcpy_chk results in a full evaluation of the object size
> argument and consequent replacement with either a strcpy call or a
> __strcpy_chk call depending on whether the access is safe.  __strcpy_chk
> is, well, just __strcpy_chk.
>
> That said though, gcc has a gimple_fold_builtin_stxcpy_chk which folds
> __strcpy_chk calls into a strcpy if the access is known to be safe, so
> from that perspective, it doesn't actually make a difference as far as
> gcc is concerned.  I don't know if clang has similar optimizations.
>

This is only for testing.  This passed tests for both GCC and clang.


> TL;DR; I think this is fine as far as gcc is concerned.
>
> Thanks,
> Sid
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241218/10dd5100/attachment.htm>