From: tr.17687@z991.linuxsc.com   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)