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