From: chris.m.thomasson.1@gmail.com   
      
   On 11/2/2025 9:59 PM, Kaz Kylheku wrote:   
   > 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.)   
      
   Like a C program that uses a *_t postfix,  but its conforming to POSIX.   
   Clash with POSIX?   
      
      
   >   
   > 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.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)