Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Undefined behaviour in C23 Date: Mon, 15 Dec 2025 07:52:55 -0800 Organization: A noiseless patient Spider Lines: 55 Message-ID: <867bunvj1k.fsf@linuxsc.com> References: <25-08-002@comp.compilers> <25-08-003@comp.compilers> <25-08-005@comp.compilers> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 15 Dec 2025 15:53:00 +0000 (UTC) Injection-Info: dont-email.me; posting-host="3b66f75cc16331490dd39d06d7ef9603"; logging-data="2116619"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/W1L5rCJrlZy5YyfqjAC1xvCO1KN71ItQ=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:GKHcaDvBcj5gpijV1CcP/w6EDcc= sha1:ck3og7xw//lUGglGmh1CrlLckhU= Xref: csiph.com comp.lang.c:395815 James Kuyper writes: > David Brown writes: > >> On 23/08/2025 00:11, Keith Thompson wrote: > > ... > >>> David Brown 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.