This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: symbol bloat for fortify warnings


> This nop function will work for this special case, and I agree, it
> should be used.

Ok.  

> But it is no general solution.  For instance, there is a related test
> which I have not yet implemented.  If the second memset parameter is >
> 255, the called function cannot be a no-op and should not be in
> libc_nonshared.

I really don't see a problem with having this produce a no-op call for the
warning, plus the normal memset call.  In fact, I think it's preferable to
make it:

__builtin_constant_p (ch) && (ch) > 255
? (__warn_memset_ch_overflows (), __builtin_memset ((dest), (ch), (len))) : ...

so that the compiler might still choose to inline the memset (and if not it
will generate the normal "memset" call directly).  In the current
implementation, that will produce one useless call+ret for the warning
stub.  But that is only a temporary situation until we have the compiler
support to emit the warning directly without any call in the assembly emitted.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]