Re: [PATCH v2 2/3] Linux: Implement a useful version of _startup_fatal

[Florian Weimer <fweimer@redhat.com>]

* Florian Weimer:

> * Adhemerval Zanella:
>
>> On 04/05/2022 13:48, Florian Weimer wrote:
>>> diff --git a/sysdeps/unix/sysv/linux/startup.h b/sysdeps/unix/sysv/linux/startup.h
>>> new file mode 100644
>>> index 0000000000..a5de941759
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/startup.h
>>> @@ -0,0 +1,38 @@
>>> +/* Linux definitions of functions used by static libc main startup.
>>> +   Copyright (C) 2017-2022 Free Software Foundation, Inc.
>>> +   This file is part of the GNU C Library.
>>> +
>>> +   The GNU C Library is free software; you can redistribute it and/or
>>> +   modify it under the terms of the GNU Lesser General Public
>>> +   License as published by the Free Software Foundation; either
>>> +   version 2.1 of the License, or (at your option) any later version.
>>> +
>>> +   The GNU C Library is distributed in the hope that it will be useful,
>>> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> +   Lesser General Public License for more details.
>>> +
>>> +   You should have received a copy of the GNU Lesser General Public
>>> +   License along with the GNU C Library; if not, see
>>> +   <https://www.gnu.org/licenses/>.  */
>>> +
>>> +#ifdef SHARED
>>> +# include_next <startup.h>
>>> +#else
>>> +# include <sysdep.h>
>>> +
>>> +/* Avoid a run-time invocation of strlen.  */
>>> +#define _startup_fatal(message)                                         \
>>> +  do                                                                    \
>>> +    {                                                                   \
>>> +      size_t message_length = __builtin_strlen (message);               \
>>
>> Shoudn't we use double underscore name to avoid clash with local
>> variables?
>
> I think it's a problem only if message expands to something that uses
> message_length, which is as likely as __message_length.  message can't
> be a complex expression anyway because we don't want to call strlen at
> this point.

Never mind, I'm making the change.

Thanks,
Florian