From Newsgroup: comp.lang.c

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.
--- Synchronet 3.21a-Linux NewsLink 1.2