Re: "undefined behavior"?

On 13/06/2024 23:58, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

Meanwhile for over 4 decades I've been able to just write 'print foo'
with no format mismatch, because such a silly concept doesn't exist.
THAT's how you deal with it.

 By using a different language, which perhaps you should consider
discussing in a different newsgroup.  We discuss C here.

That was my point about the 3 decades it took to do something about it. In the end nothing really changed.

If foo is an int, for example, printf lets you decide how to print
it (leading zeros or spaces, decimal vs. hex vs. octal (or binary
in C23), upper vs. lower case for hex).  Perhaps "print foo" in
your language has similar features.

The format string specified two things. One is to do with the type of an expression, which the compiler knows. After all that's how sometimes it can tell you you've got it wrong.
And if it can do that, it could also put in the format for you.

Yes, the fact that incorrect printf format strings cause undefined
behavior, and that that's sometimes difficult to diagnose, is a
language problem.  I don't recall anyone saying it isn't.  But it's
really not that hard to deal with it as a programmer.
 If you have ideas (other than abandoning C) for a flexible
type-safe printing function, by all means share them.  What are your
suggestions?

A few years ago I played with a "%?" format code in my 'bcc' compiler and demonstrated it here. The ? gets replaced by some suitable format code. This is done within the compiler, not the printf library.
For other display control, such as hex output, or to provide other info such as width, that still needs to be provided as it is done now.
This would cover most of my points except variable format strings, which you said were not worth worrying about.
Here is a demo:
--------------------------
#include <stdio.h>
#include <stdint.h>
#include <time.h>
int main(void) {
     uint64_t  a = 0xFFFFFFFF00000000;
     float     b = 1.46;
     int       c = -67;
     char*     d = "Hello";
     int*      e = &c;
     for (int i=0; i<100000000; ++i);
     clock_t   f = clock();
     printf("%=? %=? %=? %=? %=? %=?\n", a, b, c, d, e, f);
     printf("%=? %=? %=? %=? %=? %=?\n", f, e, d, c, b, a);
}
--------------------------
This prints 6 variables of diverse types with a suitable default format. Then it prints then in reverse order, without having to change those format codes.
The '=' is an extra feature which displays the name of the argument.
The output from this was:
A=18446744069414584320 B=1.460000 C=-67 D=Hello E=000000000080FF08 F=219
F=219 E=000000000080FF08 D=Hello C=-67 B=1.460000 A=18446744069414584320
It's not quite as good as my language where it's just:
    println =a, =b, =c, =d, =d, =f
but I think it was an interesting experiment. This required 50 lines of code within my C compiler; a bit more for a full treatment.
   Adding `print` as a new keyword so you can use `print

foo` is unlikely to be considered practical; I'd want a much more
general mechanism that's not limited to stdio files.  Reasonable new
language features that enable type-safe printf-like functions could
be interesting.  I'm not aware of any such proposals for C.
 

We just can't have size_t variables swilling around in prgrams for these
reasons.

POSIX defines a set of strings that can be used by a programmer to
specify the format string for size_t on any given implementation.

>
And here it just gets even uglier. You also get situations like this:
>
     uint64_t i=0;
     printf("%lld\n", i);
>
This compiles OK with gcc -Wall, on Windows64. But compile under
Linux64 and it complains the format should be %ld. Change it to %ld,
and it complains under Windows.
>
It can't tell you that you should be using one of those ludicrous macros.

 And you know why, right?  uint64_t is a typedef (an alias) for some
existing type, typically either unsigned long or unsigned long long.
If uint64_t is a typedef for unsigned long long, then i is of type
unsigned long long, and the format string is correct.
 Sure, that's a language problem.  It's unfortunate that code can be
either valid or a constraint violation depending on how the current
implementation defines uint64_t.  I just don't spend much time
complaining about it.
 I wouldn't mind seeing a new kind of typedef that creates a new type
rather than an alias.  Then uint64_t could be a distinct type.
That could cause some problems for _Generic, for example.
 C99 added <stdint.h>, defining fixed-width and other integer types using
existing language features.  Sure, there are some disadvantages in the
way it was done.  The alternative, creating new language features, would
likely have resulted in the proposal not being accepted until some time
after C99, if ever.
 

I've also just noticed that 'i' is unsigned but the format calls for
signed. That may or may not be deliberate, but the compiler didn't say
anything.

 The standard allows using an argument of an integer type with a format
of the corresponding type of the other signedness, as long as the value
is in the range of both.  (I vaguely recall the standard's wording being
a bit vague on this point.)