generalize errno handling
Rich Felker
dalias at aerifal.cx
Thu Mar 24 12:42:11 UTC 2011
On Wed, Mar 23, 2011 at 10:50:02PM +0100, Laurent Bercot wrote:
> >> the point is to not have the overhead of an indirect pointer in the
> >> non-threaded case. are you suggesting we force that overhead when it
> >> is unnecessary ?
> > yes
>
> No thanks. Some of us out there still know how to write software
> without threads, and we would very much like to be able to keep using
> a lean, clean libc and build executables that are *not* polluted by
> the overwhelming "threads or gtfo" fad.
I must say it's utterly hypocritical and simply anti-thread FUD to
care about a few bytes/cycles around errno accesses and not all the
other gigantic unnecessary bloat that's crept into uclibc (look at the
init code and stdio, not to mention all the functionality copied
directly from glibc) which is at least ten times bigger and more
expensive at runtime. "Micro-optimizing" errno access for non-threaded
builds has just been a maintenance nightmare - I regularly run into
people encountering problems with errno always being zero or simply
build errors when using semi-obscure build settings or platforms,
simply because there's too much complexity, too many combinations of
options, etc. Stripping all that out and merely cutting down the
unconditional bloat that's all over the place would do a lot more to
reduce size.
Rich
More information about the uClibc
mailing list