Re: Suggested method for returning a string from a C program?

bart <bc@freeuk.com> wrote:

 
Sorry, but there's something wrong if you have to write all that to get
a handful of fixed-width types. (And if this is for a multitude of
targets, then there should be a dedicated header per target).
 
GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
of the core language, it would be zero lines.

You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.
So about 72 lines in compiler.  For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).

stdint.h defines quite a bit more than just types, so actual
saving from having them built into compiler would be small,
in particular since preprocessor is fast.  On my machine
I see 91 code lines after preprocessing of stdint.h.  And
actually, several of definitions like '__pid_t' go beyond C
and are needed by other headers.  So, really is not a big
deal.

BTW: I just tried

/tmp$ time gcc -E foo.c | wc
1000006 2000022 12889013

real 0m0.359s
user 0m0.351s
sys 0m0.085s

So gcc preprocessor is able to handle almost 3 million lines
per second.  The lines were short, but gcc goes trough
piles of header files resonably fast, probably much faster
than you think.

I also tried to compile file contaning 100000 declarations
like:

extern int a0(void);
....
extern int a999999(void);

Compilation of such file takes 1.737s, so about 575000 lines
per second.  So a lot of function declarations in header
files should not slow gcc too much.  Typedefs seem to
trigger quadratic behaviour, so a lot of typedefs is likely
to slow down gcc quite a lot.  But a limited bunch of
typedefs should not be too bad.  And it probably does not
make much difference if the typedefs are in source file
or built into compiler.

--
                              Waldek Hebisch