From: 643-408-1753@kylheku.com   
      
   On 2025-11-01, Tristan Wibberley  wrote:   
   > On 01/11/2025 03:46, Kaz Kylheku wrote:   
   >> On 2025-10-31, Tristan Wibberley  wrote:   
   >>> On 31/10/2025 18:06, Richard Damon wrote:   
   >>>> [H and H1] fail to be correct C   
   >>>> interpreters, as the code has a required diagnostic.   
   >>>   
   >>> Really? even in K&R C?   
   >>   
   >> It doesn't require a diagnostic in ISO C. It has undefined behavior.   
   >>   
   >> As far as K&R C goes, if the K&R book is mum about this issue,   
   >> it may be regarded as undefined in that old dialect also.   
   >>   
   >> When a program makes use of an external name (other than in certain   
   >> ways like "sizeof name") and that name is not defined exactly once   
   >> the behavior is undefined.   
   >   
   > Does it have to be defined in C?   
      
   For the behavior to be well-defined, yes; it has to be defined in a a   
   translation unit of the program, or else be one of the external names in   
   the standard library.   
      
   Other possibilities that are valid are beyond the scope of ISO C, such   
   as mixed-language programming:   
      
   - defining an external name in Fortran or assembly.   
      
   - additonal libraries provided by the toolchain/platform, allowing   
     the program to use names which are not in ISO C and which it   
     does not define.   
      
   All of these are examples of documented extensions. Documented   
   extensions de facto create a larger local dialect of C in which   
   more things are defined, but which is less portable.   
      
   >> Linking is not required to fail with a diagostic in that situation, and   
   >> that has certain implications of practical importance.   
   >>   
   >> For instance, if you are on Unix, this program will succesfully   
   >> link, even though it uses a function which is not in the program   
   >> and not in the standard C language:   
   >   
   > What is under the scope of the term "the program" and how does that   
   > compare to "the translation unit" ?   
      
   A program consists of linking together one or more translation units.   
      
   > If I put a definition in a separate translation unit can it be part of   
   > the program?   
      
   Yes.   
   >   
   > If I put the separate translation unit in /usr/src can it be part of the   
   > program?   
      
   Yes. ISO C doesn't specify the details of how these materials are   
   laid out in a file system: the entire manner of how the materials   
   are gathered up and presented for translation and linking.   
      
   > If I put the separate translation unit in the C-interpreter, can it be   
   > part of the program?   
      
   If you're working on a C interpreter, your role is almost certainly that   
   of the implementor. The C interpreter could provide the library in the   
   form of a translation unit which is implicitly combined with any other   
   translation unit coming from the implementation user.   
      
   There is an issue with providing libraries beyond those described   
   in ISO C. C does not have a namespace system.   
      
   Suppose your library has an external function foo, as an extension.   
      
   This name is not in ISO C and is not reserved as an external name;   
   therefore even strictly conforming ISO C programs are allowed   
   to use it.   
      
   The implementation must do whatever it takes to allow ISO C programs to   
   use such identifiers, even if they clash with its own extensions.   
      
   On GNU/Linux systems, this is done with weak symbols. For instance   
   the POSIX function read() is a weak symbol such that if the   
   application defines its own external name read, it will suppress   
   that one; the weak symbol crumbles out of the way, so to speak.   
      
   Now the library itself needs to use read(), for nstance for implementing   
   the standard C getchar(). The library does not go through the   
   weak alias, but uses the real name like __libc_read. Thus it is   
   unaffected by the alias being redefined.   
      
   (A C program that defines the name __libc_read is not   
   strictly conforming; that /is/ in a reserved namespace, unlike read.)   
      
   Systems without weak symbols may satisfy the requirement by carefully   
   segmenting their libraries, rather than providing one large library   
   or several large ones, that are broadly inclusive of material.   
      
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)