Groups | Search | Server Info | Login | Register

Groups > comp.compilers > #3689

Re: Undefined behaviour in C23

Cross-posted to 2 groups.

Show all headers | View raw

David Brown <david.brown@hesbynett.no> writes:
> On 23/08/2025 00:11, Keith Thompson wrote:
...
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 21/08/2025 21:53, Keith Thompson wrote:
>> [...]
>>> 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).
...
> The C standard does not define how this linking or combing is done - it
> only covers certain specific aspects of the linking that relate directly
> to C.  The behaviour of the function "foo" here is not defined in the C
> standards, and if the source code is not available when translating a
> different translation unit, the behaviour of "foo" is undefined.

I remember having an immensely frustrating discussion on this issue a
couple of decades ago.
If foo was written in fully portable C code, then that C code enables
the C standard to define what the behavior of that code is. If you lose
your last copy of the source code, you cannot confirm what that defined
behavior should be, but the behavior remains defined by the code that
has since gone missing.
The absence of that source code will make it hard to determine whether
the module can be safely linked to other modules, or to determine what
the defined behavior of the linked program should be - but if the
missing code said the right things to give the combined program defined
behavior, the implementation is still required to generate that behavior.
Not being able to determine what the standard-defined behavior of a
program should be, is for practical purposes precisely as useless as if
the behavior were undefined - but that doesn't make the behavior undefined.
And for that reason, I don't see much point in continuing to debate this
point. The last time I debated it, the discussion went on for many
months, and was not at all illuminating.

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