This is the mail archive of the mailing list for the glibc project.

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: sparc: fix for missing include file

On 12/15/2014 01:34 AM, Will Newton wrote:
Loading a zero constant into c is cheap and the side effect of the
undefined behaviour is potentially a write to memory so it is not
always going to be a performance win to do this.

It's going to be a performance win in the normal case where n != 0. It'd take a reeeaally weird usage pattern to make clearing c a performance win.

runtime analysis tools (e.g. sanitizers, valgrind) may trip over this

This is the real question. In many places, glibc is not safe in the presence of sanitizers that insert undefined behavior whenever the C standard allows them to. Current practice is for these sanitizers to maintain a list of exceptions, so that they don't cry wolf in situations like these. Should we continue this practice, or should we strive to make glibc safe even in the presence of a purposely-finicky implementation?

For strncat it doesn't matter: nobody with a clue ever uses strncat, so the only thing that matters about its performance is how many code bytes its instructions waste. For other parts of glibc, though, this question can be a big deal.

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