> 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.
Who says I don't care about the other "gigantic unnecessary bloat" ? I'm a uClibc user, not (yet) developer. I don't know the uClibc code well; if I did, and found unconditional bloat to remove, I would definitely submit patches. Give me 72 hours per day and I'll happily do it. I voiced concern about errno access because it came up, not because it's of utmost importance. Also, it's a slippery slope: a few bytes here and there might not be much, but people have already suggested, in this very list, to always pull in stdio, because, you know, *everyone* uses stdio. So I don't think my concern is unjustified, at least in principle. > "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. This is a valid point in favour of _errno_location generalization, but the original poster did not mention that. You are right: optimization should be balanced against maintenance costs. Thanks for bringing it up. > 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. I would welcome such an initiative, and would gladly do it myself if I didn't already have 3 other projects to finish. -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
