This is the mail archive of the
mailing list for the glibc project.
Re: sparc: fix for missing include file
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: David Miller <davem at davemloft dot net>, Ondrej Bilka <neleai at seznam dot cz>, wbx at openadk dot org, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 15 Dec 2014 12:37:26 -0800
- Subject: Re: sparc: fix for missing include file
- Authentication-results: sourceware.org; auth=none
- References: <20141211 dot 150535 dot 106178897111220975 dot davem at davemloft dot net> <20141213 dot 130022 dot 1182209281374969366 dot davem at davemloft dot net> <548C8EBF dot 6010003 at cs dot ucla dot edu> <20141213 dot 143210 dot 2082290151274481189 dot davem at davemloft dot net> <548C9AC9 dot 8020608 at cs dot ucla dot edu> <CANu=DmifMhj52tF41O-pHdGSR9cBri=AC17PYsk4J1yeTS=MhQ at mail dot gmail dot com>
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.
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?
runtime analysis tools (e.g. sanitizers, valgrind) may trip over this
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.