On 10/30/25 10:49 AM, olcott wrote:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
On 10/31/25 3:57 PM, 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?
Yep, the link step will fail as H and H1 are not defined.
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> 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.
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:
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, 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?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the situation/.
On 01/11/2025 03:46, Kaz Kylheku wrote:...
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?
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" ?
On 2025-11-01 16:36, Tristan Wibberley wrote:
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, 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?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
Not in the first edition. Section 11.2 mentions that a program can be
made up of many files, and that declarations with external linkage can
refer to something defined in a different file, but that's about all
they say about it.
When the language was standardized, a lot more thought was put into it.
In C89, Section 2.1.1.2 describes the phases of translation of a
program, and phase 8 is described the link step (though it does not name
it as such): "All external object and function references are resolved. Library components are linked to satisfy external references to
functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment."
In the second edition, K&R was brought into line with the latest draft version of what would become C89. As a result, A.12 contains the
following simplified version of that specification: "The result is translated, then linked together with other programs and libraries, by collecting the necessary programs and data, and connecting external
functions and object references to their definitions."
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the
situation/.
C89 3.7 says "... If an identifier declared with external linkage is
used in an expression (other than as part of the operand of a sizeof operator), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no
more than one."
Violation of a "shall" that occurs outside of a constraints section
means that the behavior is undefined, which in turn means that the C
standard imposes no requirements on the behavior of such a program. No diagnostic is required, nor is the translation required to fail, so
Richard is wrong on those points.
Because the behavior is undefined, anything is permitted, including
providing a definition of H when the program itself contains none - but
it most certainly isn't required to do so, and I doubt that any normal C compiler would do so.
I try my best to avoid olcott messages. Does he specify that his
nonsense requires an implementation that takes advantage of undefined behavior in that fashion?
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, 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?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the situation/.
Olcott: it might help to say, instead of that H and H1 are anchored in
the interpreter, that the interpreter defines the symbol "H", if that is
what you mean for your situation (I think it is but also my C
terminology is rusty). I expect Kaz will know, he's a real dab-hand.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 01/11/2025 03:46, Kaz Kylheku wrote:
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> 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?
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" ?
If I put a definition in a separate translation unit can it be part of
the program?
If I put the separate translation unit in /usr/src can it be part of the program?
If I put the separate translation unit in the C-interpreter, can it be
part of the program?
On 2025-11-01, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 01/11/2025 03:46, Kaz Kylheku wrote:
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> 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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 81:34:18 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
7,331 files (2,461M bytes) |
| Messages: | 2,443,323 |