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

On 22/03/2025 02:37, Waldek Hebisch wrote:

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.

There's about 8, unless you include FAST/LEAST which are of interest to a minority of the minority who are even aware of them.

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).

It's a lot more than 72 lines in a compiler to support numeric types.
But this is about exposing fixed-size type aliases to existing types, which can be done fairly tidily in a compiler, but not as tidily as when all the built-in types can be expressed as one token; some need multiple tokens.
Also C requires those aliases to be hidden unless a particular header is used.
Still, I was remarking on those Q8 headers requiring 1300 lines to add these aliases.

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.

Testing -E is tricky, since the output is textual, and usually interspersed with # lines giving source line number info.
What was in foo.c?
In any case, I know that gcc can process headers reasonably fast (otherwise it would take 10 seconds to plough through windows.h at the speed of compiling code).
But it's the sheer size and scale of some headers that is the problem. Why do you think precompiled headers were invented?
Compiling this program:
   #define SDL_MAIN_HANDLED
   #include "SDL2/SDL.h"
   int main(){}
took gcc 0.85 seconds on my machine (however hello.c takes 0.2 seconds)
(SDL2 headers comprise 75 .h files and 50K lines; so about 75Kloc throughput.)
Compiling this program:
   #include <windows.h>
   int main(){}
took 1.36 seconds. window.h might comprise 100 or 165 unique headers, with 100-200K unique lines of code; I forget.
These figures are for each module that uses those headers. (My bcc took 0.07 seconds for the SDL test. The windows.h test can't be compared as my version of that header is much smaller.)

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.

I get these results (the test file has 'int main(){}' at the end):
   c:\c>tim gcc fred.c
   Time: 4.832
   c:\c>tim tcc fred.c
   Time: 4.620
   c:\c>tim bcc fred.c
   Compiling fred.c to fred.exe
   Time: 1.324
Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)