This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] New string function explicit_bzero (from OpenBSD).
On 19/08/2016 16:54, Zack Weinberg wrote:
> On Fri, Aug 19, 2016 at 12:31 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> Well, current memset_chk default implementation just does:
>>
>> if (__glibc_unlikely (dstlen < len))
>> __chk_fail ();
>>
>> So it would be feasible imho to just this add and call memset instead
>> of memset_chk.
>
> For clarity, you are imagining this as the in-libc, out-of-line
> implementation of __explicit_bzero_chk? Because as long as there's
> *some* inline definition of explicit_bzero, we have to have the
> exported __glibc_read_memory and then I don't see why we shouldn't
> have a string2.h non-fortified inline as well.
What I would like is, based on recent string inline headers cleanup,
is to avoid adding more implementation that in the future the compiler
can and would handle this transparently. Ideally it would be better if
we just aims to clean all the optimization done in string2/string3
headers (as we did for recent strspn, strbrk, etc. optimizations).
For this special case, I would advise go for the simple case: add a
explicit_bzero and __explicit_bzero_chk in-libc as the other implementations.
However I do not have a strong opinion here.
>
>> The problem, as pointed out by Florian, is not the symbol being exported
>> itself, but the inline definition where all the 'inline' definition might
>> either not being supported by the target compiler or have non-expected
>> side effects (as for C++ with -O0).
>
> Did you miss that there *is* an out-of-line non-fortified
> explicit_bzero? Which means that the bug you pointed out should be a
> non-issue.
The problem is not the existence of a out-of-line explicit_bzero, but
if __extern_inline would use or not the gnu_inline attribute. With current
guards for inclusion of string2.h (OPTIMIZE and !__cplusplus) the only
case of a possible issue I can think of is if someone building with
GCC lower than 4.2 with an optimized build and -fno-inline (this will
define __extern_inline to just extern __inline and possible create
multiple definitions). My inclination is this should not be a blocker
though.