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

bart <bc@freeuk.com> writes:

On 22/03/2025 03:50, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 21/03/2025 19:04, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

[...]

I think your response clarifies matters. Nobody cares, even as
compilers grind to a halt under all preprocessing.

If compilers ground to a halt, I would certainly care.  They don't.

>
50 modules each including GTK.h say, which was 0.33Mloc across 500
headers (so reading 16Mloc and 25,000 headers in total when all are
compiled) would not impact your builds at all? OK.

First you talked about compilers grinding to a halt, then you talked
about headers not impacting builds at all.  Those goalposts of yours
move *fast*.

>
You missed the "?".

No, I didn't.  You insinuated that I had implied that large headers
would not impact builds.  You phrased it as if you were questioning
something I had said.  I don't care to debate this specific issue
further, but please be mmore careful.

For the record, as you can see above, I did not say that builds would
not be impacted.  Do not put words into my mouth again.

>
Let me ask it again: so ploughing through a third of a million lines
of code across hundreds of #includes, even at the faster throughput
compared with compiling code, for a module of a few hundred lines,
will have little impact?
>
How about a project with 50 or 100 modules, each using that big
header, that needs to be built from scratch?

I don't know.  I haven't taken the time to measure the impact,
and if I did there wouldn't be much I could do about it.  It hasn't
particularly inconvenienced me.

Most of the builds I do from source are straightforward.  The general
pattern is roughly "configure;make;sudo make install".  I have
a wrapper script that does that, figures out what arguments to
pass, adds some extra options, and so forth.  I'm aware configures
scripts can be very large (the one for coreutils close to 95,000
lines), but I really don't care or see why I should.  It works.
Building coreutils and installing 9.6 on my system took about 5
minutes, during which I was able to go off and do other things.

Could the whole thing be streamlined?  Could a new version of the
autotools be developed that doesn't cater as much to obsolete systems
and generates smaller configure scripts?  Would it substantially
improve build times?  Quite possibly, but I'm not likely to be the
one to work about the details (unless someone wants to hire me to
look into it).

[...]

So let me ask /this/ again: if such a library consisted of ONE compact
header file, would it make the process simpler? Would it make
compilation of multiple modules faster?)

I don't know.

       printf("%v\n", t);             # (used to be '?'; changed to 'v')
   }
>
The compiler replaces the 'v' format with a conventional format code
according to the type of the expression. For my 'time_t', it happens
to be 'lld'.

That's nice.  Seriously, it's nice.  If it were added to a future
edition of the language, I'd likely use it (once I could count on it
being supported, which would take a while).
The Go language has something like that.
You can add extensions like that to your own compiler easily
enough.  Adding them to the C standard (which requires getting all
implementers to support them) is a lot harder.  Does it work for
both output (printf) and input (scanf)?  What if the format string
isn't a string literal; does the compiler generate code to adjust
it, allocating space for the translated string and deallocating it
after the call?  Does it work with printf("%n", &var)?  What about
qualifiers, specifying width, base, and so forth.

>
My feature was a proof of concept. The 60 lines of code used to test
it worked specifically for 'printf', and didn't attempt to parse
additional attributes like field widths (I wasn't implementing half of
printf).

I understand that it's a proof of concept.  My point is that all these
questions would have to be answered if it were to become part of the C
standard.  It's great that you've done a preliminary implementation, but
it doesn't do most of us any good.

It only works when the format string is a literal (but so does gcc's
checking that format codes match parameter types).

Right, if a format string isn't a literal you don't get compile-time
warnings (which are optional as far as the standard is concerned), but
you still get exactly the ame run-time semantics.

[...]

C probably introduced variadic functions just for this purpose (which
remains challenging to implement!).

I believe so, yes.  Early C implementations didn't explicitly
have variadic functions; printf was implemented in ways that
happened to work with the compiler, and later with the handful of
other compilers.  There used to be a a <varargs.h> header; C89/C90
superseded it with <stdarg.h>.

(I deal with it in my languages by having Print as a statement, with
special syntax. But internally the result is a series of function
calls (print_i64 etc); ugly, sprawling code. Users will not see it,
but I do.)

If it's a built-in statement, then user code can't use the same
mechanism.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */