Re: Undefined behaviour in C23

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: Undefined behaviour in C23
Date	2025-12-15 07:52 -0800
Organization	A noiseless patient Spider
Message-ID	<867bunvj1k.fsf@linuxsc.com> (permalink)
References	(3 earlier) <25-08-007@comp.compilers> <25-08-008@comp.compilers> <25-08-011@comp.compilers> <25-08-012@comp.compilers> <25-08-015@comp.compilers>

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

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

Right.  The key point is that not knowing what behavior will occur
doesn't change whether the behavior is defined.

Minor point: it is not implementations that generate behavior.  Per
section 1, paragraph 2, second item, programs are invoked for use by
a data-processing system, which is not part of the implementation.
But the important point remains, that definedness doesn't depend on
whether we know what behavior to expect.

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

Thread

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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 07:52 -0800

csiph-web