Groups | Search | Server Info | Login | Register

Groups > comp.compilers > #3682

Re: Undefined behaviour in C23

Show all headers | View raw

On 21/08/2025 21:53, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Under "4. Conformance", the C standards says :
>>
>> """
>> If a "shall" or "shall not" requirement that appears outside of a
>> constraint or runtime-constraint is violated, the behavior is undefined.
>>    Undefined behaviour is otherwise indicated in this International
>> Standard by the words "undefined behavior" or by the omission of any
>> explicit definition of behavior.  There is no difference in emphasis
>> among these three; they all describe "behavior that is undefined".
>> """
>>
>> So no list could ever be complete here, since anything whose behaviour
>> is not defined in the C standards is undefined behaviour. I have
>> always found that slightly at odds with the definition under "3.
>> Terms, definitions, and symbols" of "behavior, upon use of a
>> nonportable or erroneous program construct or of erroneous data, for
>> which this International Standard imposes no requirements". In my
>> mind, things like externally defined functions (used correctly) could
>> be considered UB by the section 4 definitions but not by the section 3
>> definitions.
>
> I don't see an inconsistency.
>
> A C program that includes a non-standard header that's not part of
> the program (e.g., `#include <windows.h>`) and calls a function
> declared in that header has undefined behavior as far as the C
> standard is concerned.  The program could be compiled in a conforming
> environment that has its own <windows.h> header with a declaration
> for different implementation of the same name.
>
> That's undefined behavior under both the section 3 definition (use
> of a nonportable program construct) and the section 4 definition
> (the omission of any explicit definition of behavior).
>
> [...]

If you declare and call a function "foo" that is written in fully
portable C code, but not part of the current translation unit being
compiled (perhaps it has been separately compiled or included in a
library), then it would be UB by the section 4 definition (since the C
standards don't say anything about what "foo" does, nor does your code).

But the code that calls "foo" is portable and not erroneous, so it is
not UB by the section 3 definition.

Perhaps it is possible to argue that that it is UB by both definitions,
or defined behaviour by both definitions - with enough pushing and
squeezing of how the words of the standard are interpreted.  But it is,
at best, unclear and poorly explained - even if you don't agree that it
is inconsistent.

Add to that, the C standard has a specific term for features that are
non-portable but not undefined behaviour - "implementation-defined
behaviour".  Code that relies on "int" being 32-bit is not portable, but
it is not UB when compiled on implementations for which "int" /is/ 32-bit.

As I see it, there are (at least) two significantly different types of
UB in C, by the definitions in the standard.  If you call an external
non-portable function "foo" in your code, the compiler assumes that
doing so does not result in the execution of UB - despite that being
"type 4" UB.  On the other hand, if your code dereferences a pointer,
the compiler can assume that the pointer is not invalid - because
dereferencing an invalid pointer would be "type 3" UB.

>> UB (both definitions) is an essential part of all programming languages
>> - after all, if you have a bug in your code, you have UB, and no
>> programming language has made it impossible to write bugs in your code.
>> C just has some things that are undefined in C but defined in some other
>> languages, and it is a bit more open and honest about UB than many
>> language definitions.
>
> No, a bug in your code is not necessarily undefined behavior.  It could
> easily be code whose behavior is well defined by the language standard,
> but that behavior isn't what the programmer intended.


When I write code, /I/ define what the behaviour of the code should be.
A bug in the code means it is not acting according to my definitions -
it is UB.  It may still be acting according to the definitions of the C
abstract machine given in the C standards (you are correct there).  Even
if it has C-standard UB, it will still be acting according to the
definitions of the target machine's instruction set.  Behaviour is
defined on multiple levels, only one of which is the C standard.

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

Thread

Undefined behaviour in C23 Martin Ward <mwardgkc@gmail.com> - 2025-08-20 14:06 +0100
  Re: Undefined behaviour in C23 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-20 18:33 +0000
    Re: Undefined behaviour in C23 David Brown <david.brown@hesbynett.no> - 2025-08-21 15:02 +0200
      Re: Undefined behaviour in C23 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-21 12:53 -0700
        Re: Undefined behaviour in C23 David Brown <david.brown@hesbynett.no> - 2025-08-22 17:58 +0200
          Re: Undefined behaviour in C23 anton@mips.complang.tuwien.ac.at - 2025-08-22 17:16 +0000
          Re: Undefined behaviour in C23 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-22 15:11 -0700
            Re: Undefined behaviour in C23 David Brown <david.brown@hesbynett.no> - 2025-08-23 16:55 +0200
              Re: Undefined behaviour in C23 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-23 15:58 -0700
              Re: Undefined behaviour in C23 James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-25 22:13 -0400
                Re: Undefined behaviour in C23 James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-26 13:41 -0400
                Re: Undefined behaviour in C23 Michael S <already5chosen@yahoo.com.dmarc.email> - 2025-08-26 22:28 +0300
                Re: Undefined behaviour in C23 James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-26 16:53 -0400
  Re: Undefined behaviour in C23 anton@mips.complang.tuwien.ac.at - 2025-08-21 05:44 +0000
    Re: Undefined behaviour in C23 David Brown <david.brown@hesbynett.no> - 2025-08-22 18:42 +0200
      Re: Undefined behaviour in C23 anton@mips.complang.tuwien.ac.at - 2025-09-06 17:15 +0000

csiph-web