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

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:

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

You missed the "?".

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 would download the GTK2 headers, if still available, to test it. But it would be a huge undertaking. Just the set of compiler options needed to tell it all the search paths to look for the right headers amongst the 700 files and dozen of directories would be challenging.
Usually this is done with additional tools (PKCONFIG or some such thing) because it is so complicated. With my little toy compiler however it was trial and error: look manually for each missing header, and add that to the growing list of search paths.
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?)

       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).
It only works when the format string is a literal (but so does gcc's checking that format codes match parameter types).
It only looks for "$v" and "=v"; the latter will add a label:
  #include <stdio.h>
  #include <stdint.h>
  int main(void) {
      uint64_t a = 10;
      double b = 23.1;
      void* c = main;
      printf("%=v %=v %=v\n", a, b, c);
      printf("%=v %=v %=v\n", c, a, b);
  }
The output is:
   A=10 B=23.100000 C=0000000000401000
   C=0000000000401000 A=10 B=23.100000
The motivation was partly to simplify writing lots of debug prints, which rarely have field widths.

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?

As I said the test was 60 lines of ad hoc code. It's not going to be wildly complicated. As a language feature, somebody would need to write a specification.
However, if a new format code is introduced, it should ideally be known to the printf library functions, even it can't do much with it, for those cases where it is used within a runtime string.

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.

The problem with Print is that it is a language feature that can take a arbitrary number of arguments, all of different types. Some may need formatting info.
This is challenging for a language, if it wants to do it via functions (which usually have a fixed number of arguments, of a specific type). Some advanced features may needed.
C probably introduced variadic functions just for this purpose (which remains challenging to implement!).
(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.)

That's amazing.

 Not particularly.

Sorry, I was being sarcastic. There were languages in the 60s where you could just say 'print x' and it knew how to stringify x whatever its type was. My first language using an 8KB compiler had such a Print (though not many types).

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

You get an interesting set of error messages if you write >> instead of <<.