Q <Q@ping.be> said:
[...]
> I wonder why we even have things like <linux/string.h>, it's something
> that's defined in libc.
For some stuff it makes a lot of sense. For example, the string functions
themselves are in the libc, and you just can't use them from inside the
kernel. Some of the standard headers include gunk that can't be used in the
kernel (or at least shouldn't). The string functions are again a case in
point: The glibc's str*() macros expand to truly monstrous
expressions. Just recently a tiny function along the lines:
#include <string.h>
char buff1[100], buff2[100], buff3[100], buff4[100];
char * f()
{
return strcpy(buff1,
strcpy(buff2,
strcpy(buff3,
strcpy(buff4, "*unknown*"))));
}
gives an _enormous_ preprocessed file (11+Mb here; need to turn on
optimization for this to show). Sure, that is contrieved, but such bloat in
the kernel isn't wanted.
I'm sure a fair amount of code stealing is going on. Could (should?) be
more, maybe better organized. What I don't understand is not using
perfectly good compiler builtins, which do not cause such bloat. And in a
case like the above, we should measure what is going on (how much does the
glibc implementation of string functions cost, in compilation time,
executable size; how much does it buy in performance?). But hard data is
hard to come by.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:08 EST