[PATCH v2] Replace __strcpy_chk with __builtin___strcpy_chk

[Sam James]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:

> 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.

Ouch, thanks (and sorry). Let's do the v1 one version given I don't know
Clang's behaviour there.

>
> TL;DR; I think this is fine as far as gcc is concerned.
>
> Thanks,
> Sid