Re: "undefined behavior"?

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups	comp.lang.c
Subject	Re: "undefined behavior"?
Date	2024-06-13 15:58 -0700
Organization	None to speak of
Message-ID	<87le385u1s.fsf@nosuchdomain.example.com> (permalink)
References	(4 earlier) <666a2a30$0$952$882e4bbb@reader.netnews.com> <87tthx65qu.fsf@nosuchdomain.example.com> <v4dtlt$23m6i$1@dont-email.me> <NoEaO.2646$J8n7.2264@fx12.iad> <v4fc5j$2cksu$1@dont-email.me>

Show all headers | View raw

bart <bc@freeuk.com> writes:
> On 13/06/2024 16:39, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 13/06/2024 01:33, Keith Thompson wrote:
>>>>
>>>> printf is a variadic function, so the types of the arguments after
>>>> the format string are not specified in its declaration.  The printf
>>>> function has to *assume* that arguments have the types specified
>>>> by the format string.  This:
>>>>       printf("%d\n", foo);
>>>> (probably) has undefined behavior if foo is of type size_t.
>>>>
>>> And isn't that a nightmare?
>> No, because compilers have been able to diagnose mismatches
>> for more than two decades.
>
> What about the previous 3 decades?

They're over.  Sheesh.

> What about the compilers that can't do that?

Use a compiler that can.  If you're using a compiler for production that
can't produce the warnings, you can even use a different compiler just
to get the warnings (if your code isn't too dependent on the compiler
you're using).  Code reviews also help.

> What about even the latest gcc 14.1 that won't diagnose it even with
> -Wpedantic -Wextra?

I don't know.  The default gcc on my system diagnoses it by default, but
various versions of gcc I've built from source do not.  Perhaps Ubuntu
configures gcc differently.  (Ubuntu 22.04.4, gcc 11.4.0.)  I'm building
gcc 11.4.0 from source, and I'll compare its behavior to that of
Ubuntu's gcc 11.4.0-1ubuntu1~22.04.

The "-pedantic" option enables diagnostics that are required by the C
standard.  I wouldn't expect it to enable optional warnings like those
for format strings.

The "-Wextra" option enabled additional warnings that are not enabled by
"-Wall".  Common usage if you want a lot of warnings is "-Wall -Wextra".
It doesn't make much sense to use "-Wextra" by itself.

You've used an unusual set of options that avoid enabling format string
warnings.

Format string warnings are enabled by "-Wformat", which is included in
"-Wall".

On serious projects, gcc is rarely invoked with default options.
If you don't like the default settings, I'm likely to agree with
you, but specifying the options you want is a lot more effective
than complaining.

But the mechanism for enabling the warning, and whether it's enabled by
default, is a gcc issue, not a C issue.

> What about when the format string is a variable?

Then the compiler probably won't be able to diagnose it.  (How often
do you use a variable format string?)

> What about the example given below?
>
> It is definitely a language problem. Dealing with some of it with some
> compilers with some options isn't a solution, it's just a workaround.

Because C doesn't have the language features necessary for the library
to provide something as flexible as printf with more type safety.

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

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.

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

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

"undefined behavior"? DFS <nospam@dfs.com> - 2024-06-12 16:47 -0400
  Re: "undefined behavior"? Barry Schwarz <schwarzb@delq.com> - 2024-06-12 14:30 -0700
    Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-12 17:53 -0400
      Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 15:30 -0700
        Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-12 19:07 -0400
          Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 17:33 -0700
            Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-13 05:47 +0100
              Re: "undefined behavior"? scott@slp53.sl.home (Scott Lurndal) - 2024-06-13 15:39 +0000
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-13 18:08 +0100
                Re: "undefined behavior"? bart <bc@freeuk.com> - 2024-06-13 19:01 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-13 19:54 +0100
                Re: "undefined behavior"? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-13 12:34 -0700
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 00:32 +0100
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-14 00:55 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 02:48 +0100
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-14 12:44 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 15:30 +0100
                Re: "undefined behavior"? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-14 16:32 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 19:06 +0100
                Re: "undefined behavior"? bart <bc@freeuk.com> - 2024-06-14 19:31 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 20:13 +0100
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-14 22:29 +0100
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 23:35 +0100
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-15 00:14 +0100
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-15 20:57 +0200
                Re: "undefined behavior"? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-15 20:27 +0100
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-15 23:13 +0100
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-16 12:53 +0200
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 14:44 +0100
                Re: "undefined behavior"? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-14 11:49 -0700
                Re: "undefined behavior"? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-14 22:32 +0100
                Re: "undefined behavior"? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-15 00:56 -0700
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-13 15:58 -0700
                Re: "undefined behavior"? bart <bc@freeuk.com> - 2024-06-14 02:18 +0100
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-14 19:08 +0200
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 12:34 -0700
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-15 22:13 +0200
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 13:43 -0700
              Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-13 14:47 -0700
                Re: "undefined behavior"? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-14 00:41 +0100
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-13 17:09 -0700
  Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-12 23:38 +0200
    Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 15:18 -0700
      Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-13 14:42 +0200
        Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-13 16:39 -0700
      Re: "undefined behavior"? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:23 -0700
        Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 17:42 -0700
          Re: "undefined behavior"? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-22 09:28 -0700
    Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-12 18:29 -0400
      Re: "undefined behavior"? Ike Naar <ike@sdf.org> - 2024-06-13 07:25 +0000
        Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-13 11:13 -0400
          Re: "undefined behavior"? scott@slp53.sl.home (Scott Lurndal) - 2024-06-13 15:40 +0000
          Re: "undefined behavior"? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-13 15:49 +0000
            Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-13 13:05 -0400
      Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-13 15:15 +0200
        Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-13 16:47 -0700
          Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-14 19:13 +0200
  Re: "undefined behavior"? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-12 23:38 +0200
    Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 15:22 -0700
      Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-12 18:34 -0400
        Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-13 15:21 +0200
          Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-13 10:38 -0400
            Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-14 19:18 +0200
              Re: "undefined behavior"? scott@slp53.sl.home (Scott Lurndal) - 2024-06-14 17:36 +0000
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-15 22:15 +0200
              Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-14 19:05 -0400
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 18:39 -0700
                Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-14 23:49 -0400
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 20:56 -0700
                Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-15 00:45 -0400
                Re: "undefined behavior"? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-15 07:03 +0200
                Re: "undefined behavior"? DFS <nospam@dfs.com> - 2024-06-15 07:39 -0400
                Re: "undefined behavior"? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-15 01:05 -0400
                Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 22:20 -0700
                Re: "undefined behavior"? bart <bc@freeuk.com> - 2024-06-15 09:37 +0100
                Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-15 22:22 +0200
      Re: "undefined behavior"? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-13 02:19 +0200
        Re: "undefined behavior"? David Brown <david.brown@hesbynett.no> - 2024-06-13 15:28 +0200
  Re: "undefined behavior"? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 14:57 -0700
  Re: "undefined behavior"? bart <bc@freeuk.com> - 2024-06-13 10:43 +0100
  Re: "undefined behavior"? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-13 11:45 +0200

csiph-web