From Newsgroup: comp.lang.c

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

From Newsgroup: comp.lang.c

On 2025-08-25 22:13, James Kuyper wrote:
...

I remember having an immensely frustrating discussion on this issue a
couple of decades ago.

The discussion was on comp.std.c, the Subject: was "clrsc and UB", and
my participation in the discussion started 2002-02-05.
[Yeah, it's not like this is a new topic. -John]
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 26 Aug 2025 13:41:14 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 2025-08-25 22:13, James Kuyper wrote:
...

I remember having an immensely frustrating discussion on this issue
a couple of decades ago.

The discussion was on comp.std.c, the Subject: was "clrsc and UB", and
my participation in the discussion started 2002-02-05.
[Yeah, it's not like this is a new topic. -John]

Don't you mean "clrscr and UB" ?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-08-26 15:28, Michael S wrote:

On Tue, 26 Aug 2025 13:41:14 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

...

The discussion was on comp.std.c, the Subject: was "clrsc and UB", and
my participation in the discussion started 2002-02-05.
[Yeah, it's not like this is a new topic. -John]

Don't you mean "clrscr and UB" ?

I didn't think I could mess up something that short, so I typed it by
hand. :-(
--- Synchronet 3.21a-Linux NewsLink 1.2