Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Sat, 22 Mar 2025 13:50:24 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vrmf6u$2nif7$1@paganini.bofh.team>
References: <vrd77d$3nvtf$2@dont-email.me>   <20250319115550.0000676f@yahoo.com> <vreuj1$1asii$4@dont-email.me> <vreve4$19klp$2@dont-email.me> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> <vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad> <vrh71t$3be42$1@dont-email.me> <874izntt5t.fsf@nosuchdomain.example.com> <vrhviu$h5c$1@dont-email.me> <87ecyrs332.fsf@nosuchdomain.example.com> <vri9t1$a29t$1@dont-email.me> <vrl7p7$2lnkl$1@paganini.bofh.team> <vrm9v3$3uioh$1@dont-email.me>
Injection-Date: Sat, 22 Mar 2025 13:50:24 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2869735"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 8635
Lines: 191

bart <bc@freeuk.com> wrote:
> 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.

Well, FAST/LEAST types are mandatory for standard compliance.

>> 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,

Yes, there is complex machinery to support types and compiler
data structires in general.  But once machinery is in place
you need to create type node and insert it into symbol table.
In gcc creation of type node may look like:

  sizetype = make_node (INTEGER_TYPE);
  TYPE_NAME (sizetype) = get_identifier ("sizetype");
  TYPE_PRECISION (sizetype) = precision;
  TYPE_UNSIGNED (sizetype) = 1;
  scalar_int_mode mode = smallest_int_mode_for_size (precision);
  SET_TYPE_MODE (sizetype, mode);
  SET_TYPE_ALIGN (sizetype, GET_MODE_ALIGNMENT (TYPE_MODE (sizetype)));
  TYPE_SIZE (sizetype) = bitsize_int (precision);
  TYPE_SIZE_UNIT (sizetype) = size_int (GET_MODE_SIZE (mode));
  set_min_and_max_values_for_integral_type (sizetype, precision, UNSIGNED);

But such things are repeated for several types, so one can have
function like 'create_integer_type_node' which is doing the above,
but for type name and precision which are arguments to the function.

Of course, if you need to do soemthing special to a type, then
you may need a lot of code.  But integer types should be handled
anyway, so there is really no special code beyond what is already
there.

> but not as tidily as when 
> all the built-in types can be expressed as one token; some need multiple 
> tokens.

Unlike classic integer types, types in stdint.h have names which
are single token, so all you need to do is to insert entry in the
symbol table.

> Also C requires those aliases to be hidden unless a particular header is 
> used.

Yes, so either one need some mechanism to hide/expose builtin
indentifiers, or (what is typically done) one need to use
reserved names for builtin indentifiers and use stdint.h to
define standard name as an alias.

> Still, I was remarking on those Q8 headers requiring 1300 lines to add 
> these aliases.

I am not sure if Q8 really needed all those lines.  But you
should take into account that it provided type without
cooperation with the compiler.

>> 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?

Just 1000000 lines of declarations (no includes etc.).  The
point was that skipping input is easier than copying things to
the output, so that should give reasonable estimate of time
spent on parts that disappear after preprocessing.

> 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?

Some headers are pretty big.  But fact that at source level
stdint.h has some hundreds of lines is not big problem, it
is still rather small.  Note that it is convenient to have
common headers for variants of architecure, on my Linux
I can run 3 kinds of programs: classic 32-bit ones, 64-bit ones
and x32 (which uses 32-bit addresses, but uses 64-bit
instructions).  Each needs slightly different definitions
in header files.  This is handled by conditionals in
header files.  And in fact large part of headers are shared
with different architecures (and even different OS-es using
the same libc).

> 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
                                          ^^^^^^
Oops, should be 1000000.

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

On my machine tcc preprocesses probably about 20% faster than gcc.
For timing compilation I used 'gcc -c' to generate linkable object
file, so no need to have 'main'.  When actually compilning on my
machine tcc is significantly faster, on the same file 'tcc -c'
takes 0.418s, so more than 4 times faster than 'gcc -c'.

========== REMAINDER OF ARTICLE TRUNCATED ==========