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

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

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.

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.

 Scripting languages like Perl and Python have
print functions that take arguments of arbitrary types, and ways
to interpolate numeric values into string literals.  And so on.
 I'm not sure what would be the best way to add something like this
in C202y or C203z.  There are arguments against adding too many new
features to C when other languages are available; if C became C++
Lite, a lot of programmers would just use C++.  There are a number
of different approaches that could be taken, and choosing among
them is not trivial.

See above.

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
acknowledge when people take the time to explain it.

This forum tends to not be critical of the language. But even if aspects of it can't be changed, there's no reason not to call them out.