Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Fri, 21 Mar 2025 20:50:51 -0700
Organization: None to speak of
Lines: 182
Message-ID: <87cye9afl0.fsf@nosuchdomain.example.com>
References: <vrd77d$3nvtf$2@dont-email.me> <868qp1ra5f.fsf@linuxsc.com>
	<vrdhok$47cb$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> <20250320171505.221@kylheku.com>
	<vrif1v$c9ev$3@dont-email.me>
	<8734f7rw7z.fsf@nosuchdomain.example.com>
	<vrjjvb$1esjh$1@dont-email.me>
	<87tt7mqk7w.fsf@nosuchdomain.example.com>
	<vrkvt5$2k04q$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 22 Mar 2025 04:50:55 +0100 (CET)
Injection-Info: dont-email.me; posting-host="560ef87f14dda6eab647556d5657da3c";
	logging-data="3124311"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/yUA6qCVuFxB6SEs3J8wOK"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:+Fo2oKCI6jXWSB8s1tX3hV7CtVo=
	sha1:SfA04JGt+VEmjIdBCr7Tj0XdNW8=
Bytes: 10073

bart <bc@freeuk.com> writes:
> On 21/03/2025 19:04, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 21/03/2025 01:47, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> You're complaining about how much work it is.  All that work
>>>> has been done for you by the implementers.  Decades ago.
>>>
>>> We are talking about defining types like 'int32' on top of 'char short
>>> int long', yes? Then how difficult could it possibly be?
>> If you want <stdint.h> and <inttypes.h> headers that work correctly
>> with all relevant compilers, it's not particularly easy.  I'll note
>> that the MUSL implementation of <stdint.h> is 117 lines, compared to
>> 308 for GNU libc.
>> 
>>>> I just did a quick test comparing complation times for an empty
>>>> program with no #include directives and an empty program with
>>>> #include directives for <stdint.h> and <inttypes.h>.  The
>>>> difference was about 3 milliseconds.  I quite literally could not
>>>> care care less.
>>>
>>> I'm sorry but that's a really poor attitude, with bad
>>> consequences. You're saying it doesn't matter how complex a header or
>>> set of headers is, even when out of proportion to the task.
>>>
>>> But this is why we end up with such complicated headers.
>> Complicated headers that work.
>> [...\
>> 
>>> 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*.

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.

> But I expect if a major library supplier came out with the idea of a
> streamlined, compact one-file header that took 90% less compile-time,
> that would be hailed as a brilliant advance!
>
>>>>> Doing stuff the C way requires LOTs of lines of code. Look at all
>>>>> those MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!
>>>> So what?  I don't have to read those lines of code.  All I have to
>>>> read
>>>> is the standard (or some other document) that tells me how to use it.
>>>
>>> It is crass. But it also affects the programmer because they have to
>>> explicitly include that specific header and then remember the
>>> dedicated MIN/MAX macros for the specific type. And they have to
>>> /know/ the type.
>> Yes, of course.
>> 
>>> If the type is opaque, or is an alias, then they won't know the name
>>> of the macro. If the typedef is 'T' for example, then what's the macro
>>> for its MAX value? Which header will they need?
>> There may not be one.  For example, there's no format specifier for
>> time_t.  If I need to print a time_t value, I'll probably cast to
>> intmax_t and use "%jd".  If I'm being obsessive about portability, I'll
>> test whether time_t is signed, unsigned, or floating-point (all of which
>> are possible in principle), and use "%jd", "%ju", or "%Lf".
>
> I wonder if you realise how utterly ridiculous all those incantations sound?

That's a matter of opinion.  I see your point, but they're not nearly as
ridiculous to someone who knows the language or who isn't looking for
things to complain about.

> This is a C program using one of the extensions from my old compiler:
>
>   #include <stdio.h>
>   #include <time.h>
>
>   int main(void) {
>       time_t t = clock();
>       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.  How do I print
an integer of arbitrary type in hexadecimal in a right-justified
8-digit zero-padded field?  The feature implies an ability for
generic code that works with different types; can programmers use
that feature for things other than format strings?  How much more
complicated would the C language (as distinct from the library)
have to be to support this?

If you have answers to all those questions, and to all the other
questions that haven't occurred to me, I wouldn't mind seeing
something like that in a future version of C.  I haven't looked
closely at Go, but it's a compiled language with a feature similar
to what you describe; it could probably be mined for ideas.

Or maybe we should be thinking in terms of something other than format
strings.  The idea that "%v", which is a 3-byte chunk of data, has
compile-time implications in certain contexts is a bit unnerving.

Ada chose the short name "Put" for its output routines.
It's overloaded, so you can write `Put(this); Put(that);
Put(the_other);` Maybe that a little too verbose, but how about
a new built-in operator that takes an argument of any of various
types and yields something that can be printed?  '$' is available.
I haven't thought this through.

Oh, sorry, did I violate your assumption that all I do is attack your
ideas?  (Disclaimer: I'm not sure you've said that in those words.)

>>> In a certain language I use, it will be T.max (and there are no
>>> headers). I'm not suggesting that C turns into that language, only
>>> that somebody acknowledges the downsides of using C's approach, since
>>> again nobody cares.
>> I acknowledge the downsides of C's approach.  See, all you had to
>> do was ask.
>> As Dennis Ritchie said, "C is quirky, flawed, and an enormous
>> success".
>
> So it's quirky and flawed.

Yes, and an enormous success.

>> It would be very nice if C had some kind of more generic I/O that
>> doesn't require remembering arbitrary format strings and qualifiers
>> for each type, and that doesn't provide format strings for a lot of
>> types in the standard library, and certainly not for types defined
>> in user code.  And I'd *love* it if a future C standard removed
>> the undefined behavior for numeric input using *scanf().  Other C
>> programmers will have different priorities than yours or mine.
>> If I want to print a time_t value in C++, I just write
>> `std::cout << t` and the compiler figures out which overloaded
>> function to call.
>
> That's amazing.

Not particularly.  C has programmer-defined operator (and function)
overloading as a language feature.  (There are IMHO some serious
flaws in C++'s use of overloaded "<<" for output, but I won't go
into that here.)

[...]

>> When I talk about how to work with C as it's currently defined,
>> you tend to see advocacy where it doesn't exist.  When you complain
>> about things in C that I don't think are real problems, you tend
>> to assume that I'm saying C is perfect, something I've never said.
>> When you ask why something in C is defined the way it is, you don't
========== REMAINDER OF ARTICLE TRUNCATED ==========