On 10/24/23 8:54 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> The point isn't quite the same. The C standard explicitly says
>>> integers may be converted to any pointer type. The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type. Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree. (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint. It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
>
> First let me ask a question. Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

"A strictly conforming program shall use only those features of the
language and library specified in this International Standard.3) It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit." (4p5)

DR 109 addresses a function named foo() which contains the line "1/0;",
but there was no guarantee that the function would ever be called - in
fact, the function definition was the only part of the program mentioned
in the DR. The committee ruled that:

"... if every possible execution of a given program would result in
undefined behavior, the given program is not strictly conforming.
A conforming implementation must not fail to translate a strictly
conforming program simply because some possible execution of that
program would result in undefined behavior. Because foo might never be
called, the example given must be successfully translated by a
conforming implementation. "

In DR 109, the program was not guaranteed to execute 1/0. The program
that Keith provided (which you snipped) is much safer - it uses an if(0)
to guarantee that the code that might have undefined behavior will NOT
be executed. If the DR109 code doesn't prevent the program from being
strictly conforming, this certainly should not.

The standard never talks about rejection. It requires that "A conforming
hosted implementation shall accept any strictly conforming program.". No
such requirement applies to any program which is not strictly
conforming. (4p6)

Therefore, this code must be accepted.

On 2023-10-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> First let me ask a question. Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

I think, yes.

"This document does not specify
[...]
— the size or complexity of a program and its data that will exceed the
capacity of any specific data-processing system or the capacity of a
particular processor;"

"The implementation shall be able to translate and execute a program
that uses but does not exceed the following limitations for these
constructs and entities ..."

There can be programs which stay within the limits, and are even
strictly conforming, which an implementation might not handle.

An implementation has to demonstrate translating and executing only one
("a") program which strains all the limits. It is not spelled out who
gets to choose the test case. Either the implementors choose the test
case, or else if their users choose the test cases, the implementors can
fix whatever it takes to make just one of them pass, and then the
conformance requirement is satisfied.

That leaves margin for the existence of strictly conforming programs
that are not handled.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-10-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> The standard never talks about rejection. It requires that "A conforming
> hosted implementation shall accept any strictly conforming program.". No
> such requirement applies to any program which is not strictly
> conforming. (4p6)
>
> Therefore, this code must be accepted.

What does "accept" mean? I don't see it defined. If it means
"successfully translate and execute", then what is the point of the
requirement that a conforming implementaton must successfully translate
and execute "a" program that contains an instance of every limit? If
"accept" means "translate and execute", then the above quoted
requirement means that the implementation must accept every possible
such program, not just "a" program.

Might "accept" might mean, roughly, parse the syntax, check constraints
and report no issues that would stop further translation?

Or possibly, successfully translate and link the program, without
assurance that it can be executed?

The thing is, if it can't execute, that's as good as rejected.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/25/23 02:46, Kaz Kylheku wrote:
> On 2023-10-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> The standard never talks about rejection. It requires that "A conforming
>> hosted implementation shall accept any strictly conforming program.". No
>> such requirement applies to any program which is not strictly
>> conforming. (4p6)
>>
>> Therefore, this code must be accepted.
>
> What does "accept" mean? I don't see it defined. ...

Correct. In the absence of a standard-defined meaning, we're left with
the ordinary English meaning of the word. Since I can accept a gift
without, in any way, being obligated to do anything with it, I've argued
that a implementation could meet that requirement by issuing the message
"Program accepted", and doing nothing else with it. The message, not
being a mandatory diagnostic, is optional.

The ordinary English meaning of accept is opposite to the meaning of
reject (which is neither defined nor even used in the standard). As
such, citing the text requiring strictly conforming code to be accepted,
is as close as I can come to supporting Keith's skepticism about a
conforming implementation being allowed to reject this code.

> ... If it means
> "successfully translate and execute", then what is the point of the
> requirement that a conforming implementaton must successfully translate
> and execute "a" program that contains an instance of every limit?

I fully agree. Whatever "accept" means, it must be something less strong
than "translate and execute".

....
> Might "accept" might mean, roughly, parse the syntax, check constraints

No, not entirely. A minimally-conforming implementation need only
determine that no #error directive survives conditional compilation,
something that only requires processing through translation phase 4. It
can meet the requirement by accepting all code that passes that check,
without further analysis (unless it identifies the "one program" that
it's required to do more with).

> and report no issues that would stop further translation?

Everything that would render such a report mandatory would also prevent
the code from qualifying as strictly conforming.

> Or possibly, successfully translate and link the program, without
> assurance that it can be executed?

Each implementation is required to translate and execute only one
program. That alone would be sufficient to render it unlikely that any
particular program must be executed, but the "one program" that must be
translated and executed has to meet minimum complexity requirements that
render it EXTREMELY unlikely to be the same as any particular program
that you actually want executed.

> The thing is, if it can't execute, that's as good as rejected.

Users are what requires an implementation of C to do anything useful;
the standard does not. They won't use one that doesn't. The C standard
only determines which useful things it should do, if it chooses to do them.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/25/23 02:46, Kaz Kylheku wrote:
>> On 2023-10-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> The standard never talks about rejection. It requires that "A conforming
>>> hosted implementation shall accept any strictly conforming program.". No
>>> such requirement applies to any program which is not strictly
>>> conforming. (4p6)
>>>
>>> Therefore, this code must be accepted.
>>
>> What does "accept" mean? I don't see it defined. ...
>
> Correct. In the absence of a standard-defined meaning, we're left with
> the ordinary English meaning of the word. Since I can accept a gift
> without, in any way, being obligated to do anything with it, I've argued
> that a implementation could meet that requirement by issuing the message
> "Program accepted", and doing nothing else with it. The message, not
> being a mandatory diagnostic, is optional.
>
> The ordinary English meaning of accept is opposite to the meaning of
> reject (which is neither defined nor even used in the standard). As
> such, citing the text requiring strictly conforming code to be accepted,
> is as close as I can come to supporting Keith's skepticism about a
> conforming implementation being allowed to reject this code.
>
>> ... If it means
>> "successfully translate and execute", then what is the point of the
>> requirement that a conforming implementaton must successfully translate
>> and execute "a" program that contains an instance of every limit?
>
> I fully agree. Whatever "accept" means, it must be something less strong
> than "translate and execute".

I don't agree (though I do agree that the standard is unclear on what it
means).

I don't think that printing "Program accepted" and doing nothing else
would satisfy the standard's requirements. Why would the standard have
such a completely useless requirement?

I suggest that "accept" *does* (or at least should) mean "successfully
translate and execute".

The standard does not specify "the size or complexity of a program and
its data that will exceed the capacity of any specific data-processing
system or the capacity of a particular processor" (Scope, section 1
paragraph 2) -- so *some* programs will exceed an implementation's
capacity.

5.2.4.1 says that "The implementation shall be able to translate and
execute at least one program that contains at least one instance of
every one of the following limits". That imposes a restriction on an
implementation's capacity limits. (And it does it in a way that's
straightforwardly specified, but such that the easiest non-perverse way
to conform is to have *reasonable* capacity limits.)

I suggest that the requirements in section 4, Conformance, are all
subject to any capacity limits (the ones the standard doesn't cover).
That includes 4p3:

A program that is correct in all other aspects, operating on correct
data, containing unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

and 4p6:

The two forms of *conforming implementation* are hosted and
freestanding. A *conforming hosted implementation* shall accept any
strictly conforming program. A *conforming freestanding
implementation* shall accept [snip]

My reading of all that is that a conforming implementation must
translate and execute any *correct* program and any *strictly
conforming* program **that does not exceed its capacity limits**.
Capacity limits are a valid excuse to:
- reject
- not accept
- fail to translate
- fail to execute
any program other than the "one program" of 5.2.4.1.

The program I posted upthread was:

int main(void) {
int obj = 42;
typedef void func(void);
if (0) {
func *fptr = (func*)&obj;
fptr();
}
}

I assert that a conforming hosted implementation must successfully
translate and execute it (it has no visible runtime behavior other
than returning a successful status) subject to capacity limits.
An implementation is no more or less permitted to reject it than
it is to reject "hello, world".

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-10-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> I don't think that printing "Program accepted" and doing nothing else
> would satisfy the standard's requirements. Why would the standard have
> such a completely useless requirement?

Because it forgot to define what "accept" means. Stuff happens!

ISO 2382-1 1993 doesn't define "accept" but uses the word in a way that
means receiving input before processing it:

01.03.05
analog computer
A computer whose operations are analogous to
the behaviour of another system and that accepts,
processes, and produces analog data.

To accept an input in this sense, all you have to do is buffer it and
generate any required acknowledgement signal, and then throw it away.

A definition of "accept" that is compatible with everything else in the
standard is "do not abruptly terminate without having completed
translation, and combination of translation units into a program,
regardless of the issuance of any diagnostics".

Now the host environment where translated programs execute is usually
not considered part of the implementation. The implementation may add
something to the program (like a library) but host environments exist
independently of the C language. Some host environments are produced
using tools having nothing to do with C, but are targeted by C
implementations.

The limits in what program may be executed, having been translated and
linked, are not coming from the C implementation.

Therefore, it is not reasonable to have requirements that the
implementaton must execute a program, since there are limitations in
the host environment to which the ISO C document doesn't speak,
and which the implementors may not be able to do anything about.

A C program could be compiled for a family of host systems. Some models
or installations of them may be equipped without enough resources to run
it, others not.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-10-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> I don't think that printing "Program accepted" and doing nothing else
>> would satisfy the standard's requirements. Why would the standard have
>> such a completely useless requirement?
>
> Because it forgot to define what "accept" means. Stuff happens!

Yes, they forgot to define what "accept" means. I'm expressing skepticism
that they intended to define it in such a useless manner.

> ISO 2382-1 1993 doesn't define "accept" but uses the word in a way that
> means receiving input before processing it:
>
> 01.03.05
> analog computer
> A computer whose operations are analogous to
> the behaviour of another system and that accepts,
> processes, and produces analog data.
>
> To accept an input in this sense, all you have to do is buffer it and
> generate any required acknowledgement signal, and then throw it away.
>
> A definition of "accept" that is compatible with everything else in the
> standard is "do not abruptly terminate without having completed
> translation, and combination of translation units into a program,
> regardless of the issuance of any diagnostics".

That sounds about right -- and is not consistent with printing "Program
accepted" and doing nothing else.

> Now the host environment where translated programs execute is usually
> not considered part of the implementation. The implementation may add
> something to the program (like a library) but host environments exist
> independently of the C language. Some host environments are produced
> using tools having nothing to do with C, but are targeted by C
> implementations.

Perhaps not part of the implementation, but it's within the scope of the
standard.

Section 5 (Environment):

An implementation translates C source files and executes C
programs in two data-processing-system environments, which
will be called the *translation environment* and the *execution
environment* in this International Standard. Their characteristics
define and constrain the results of executing conforming C
programs constructed according to the syntactic and semantic
rules for conforming implementations.

> The limits in what program may be executed, having been translated and
> linked, are not coming from the C implementation.
>
> Therefore, it is not reasonable to have requirements that the
> implementaton must execute a program, since there are limitations in
> the host environment to which the ISO C document doesn't speak,
> and which the implementors may not be able to do anything about.

Much of the standard defines the execution-time behavior of programs.
There is no such behavior without a working execution environment.
If `puts("hello")` prints "good-bye" because of something in the
environment, the implementation is non-conforming because it failed
to arrange for the right thing to happen at run time.

> A C program could be compiled for a family of host systems. Some models
> or installations of them may be equipped without enough resources to run
> it, others not.

True. I'd say that there has to be at least one target system that can
execute the program for the implementation to be conforming.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 10/26/23 03:10, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/25/23 02:46, Kaz Kylheku wrote:
....
>>> ... If it means
>>> "successfully translate and execute", then what is the point of the
>>> requirement that a conforming implementaton must successfully translate
>>> and execute "a" program that contains an instance of every limit?
>>
>> I fully agree. Whatever "accept" means, it must be something less strong
>> than "translate and execute".
>
> I don't agree (though I do agree that the standard is unclear on what it
> means).
>
> I don't think that printing "Program accepted" and doing nothing else
> would satisfy the standard's requirements. Why would the standard have
> such a completely useless requirement?

It has a completely useless definition of "conforming". It has 5.2.4.1,
cited by you below, which is flawed in a way that renders it essentially
useless. Why shouldn't it have other useless clauses? The committee can
make mistakes, and has even doubled down on many of them.

It has been decades since the first time I saw someone point out that
"accept" is not defined by the standard, with active committee members
participating in the discussion. I have to accept that the committee
does not feel that this is a flaw urgently in need of correction - which
I consider a mistake by the committee.

> I suggest that "accept" *does* (or at least should) mean "successfully
> translate and execute".

If the "one program" for a given implementation of C is strictly
conforming, that would render 5.2.4.1 redundant.
If the "one program" is not strictly conforming, then 5.2.4.1 serves
merely to mandate something for one program which was not strictly
conforming, which was already mandated for all strictly conforming ones.

The combination of those clauses makes sense to me only if "accept" were
meant to be somewhat less strong of a requirement than "successfully
translate and execute".

> 5.2.4.1 says that "The implementation shall be able to translate and
> execute at least one program that contains at least one instance of
> every one of the following limits". That imposes a restriction on an
> implementation's capacity limits. (And it does it in a way that's
> straightforwardly specified, but such that the easiest non-perverse way
> to conform is to have *reasonable* capacity limits.)

It does so by mandating the existence of only one program that must be
constrained by those requirements, which are minima for that program,
not maxima. That's a lousy way to specify maxima that were intended to
apply to programs other than the "one program". I agree that this seems
to have been the intent, but it fails to express that intent.

....
> My reading of all that is that a conforming implementation must
> translate and execute any *correct* program and any *strictly
> conforming* program **that does not exceed its capacity limits**.
> Capacity limits are a valid excuse to:
> - reject
> - not accept
> - fail to translate
> - fail to execute
> any program other than the "one program" of 5.2.4.1.

And as a result of the way that the standard expressed those
requirements, an implementation could have capacity limits that prevent
it from translating and executing any program other than the "one
program" that it's required to translate and execute, without failing to
conform to the standard.

>
> The program I posted upthread was:
>
> int main(void) {
> int obj = 42;
> typedef void func(void);
> if (0) {
> func *fptr = (func*)&obj;
> fptr();
> }
> }
>
> I assert that a conforming hosted implementation must successfully
> translate and execute it (it has no visible runtime behavior other
> than returning a successful status) subject to capacity limits.
> An implementation is no more or less permitted to reject it than
> it is to reject "hello, world".

I can agree that a conforming implementation is required to accept that
code, whatever it is that "accept" means - your conclusion follows from
your beliefs about what "accept" means. For myself, I believe that after
accepting such code, a fully conforming implementation can then fail to
translate and execute that code, due to it exceeding that
implementation's capacity.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/26/23 03:10, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 10/25/23 02:46, Kaz Kylheku wrote:
> ...
>>>> ... If it means
>>>> "successfully translate and execute", then what is the point of the
>>>> requirement that a conforming implementaton must successfully translate
>>>> and execute "a" program that contains an instance of every limit?
>>>
>>> I fully agree. Whatever "accept" means, it must be something less strong
>>> than "translate and execute".
>>
>> I don't agree (though I do agree that the standard is unclear on what it
>> means).
>>
>> I don't think that printing "Program accepted" and doing nothing else
>> would satisfy the standard's requirements. Why would the standard have
>> such a completely useless requirement?
>
> It has a completely useless definition of "conforming". It has 5.2.4.1,
> cited by you below, which is flawed in a way that renders it essentially
> useless. Why shouldn't it have other useless clauses? The committee can
> make mistakes, and has even doubled down on many of them.

"Conforming" (defined as "acceptable to a conforming implementation") is
not particularly useful, but it's a definition of a term, not a
requirement. I don't think anything in the standard depends on any
program being "conforming".

I don't agree that 5.2.4.1 is as flawed as you suggest it is.

> It has been decades since the first time I saw someone point out that
> "accept" is not defined by the standard, with active committee members
> participating in the discussion. I have to accept that the committee
> does not feel that this is a flaw urgently in need of correction - which
> I consider a mistake by the committee.
>
>> I suggest that "accept" *does* (or at least should) mean "successfully
>> translate and execute".
>
> If the "one program" for a given implementation of C is strictly
> conforming, that would render 5.2.4.1 redundant.
> If the "one program" is not strictly conforming, then 5.2.4.1 serves
> merely to mandate something for one program which was not strictly
> conforming, which was already mandated for all strictly conforming ones.

My interpretation (perhaps not fully supported by the wording of the
standard) is that the requirement to accept any strictly conforming
program is conditional on that program not exceeding the
implementation's capacity. You could construct a strictly conforming
program (which does not exceed any of the minimum translation limits)
that's so huge and complex that an implementation could not reasonably
be expected to translate it. A compiler might run out of memory trying
to compile it, and either crash or die with an error message before it
could even determine that the program is strictly conforming. I don't
think it's reasonable to call that "accepting" the program.

The "one program" must be one that does not exceed the implementation's
capacity. It's a way of strongly encouraging implementers to have
reasonable capacity limits.

> The combination of those clauses makes sense to me only if "accept" were
> meant to be somewhat less strong of a requirement than "successfully
> translate and execute".
>
>> 5.2.4.1 says that "The implementation shall be able to translate and
>> execute at least one program that contains at least one instance of
>> every one of the following limits". That imposes a restriction on an
>> implementation's capacity limits. (And it does it in a way that's
>> straightforwardly specified, but such that the easiest non-perverse way
>> to conform is to have *reasonable* capacity limits.)
>
> It does so by mandating the existence of only one program that must be
> constrained by those requirements, which are minima for that program,
> not maxima. That's a lousy way to specify maxima that were intended to
> apply to programs other than the "one program". I agree that this seems
> to have been the intent, but it fails to express that intent.
>
> ...
>> My reading of all that is that a conforming implementation must
>> translate and execute any *correct* program and any *strictly
>> conforming* program **that does not exceed its capacity limits**.
>> Capacity limits are a valid excuse to:
>> - reject
>> - not accept
>> - fail to translate
>> - fail to execute
>> any program other than the "one program" of 5.2.4.1.
>
> And as a result of the way that the standard expressed those
> requirements, an implementation could have capacity limits that prevent
> it from translating and executing any program other than the "one
> program" that it's required to translate and execute, without failing to
> conform to the standard.

Yes, of course. A very perverse implementation could detect the "one
program" and generate code for it (the "one program" might print "hello,
world", for example), and print a fatal capacity error for anything
else. I've been tempted to create such an implementation myself.
(Yes, I have odd ideas of fun.)

But it would have to be a deliberately useless implementation. If
you're trying to create a *useful* implementation, the easiest way to
satisfy the "one program" requirement is to have reasonably large
capacity limits, for example by having all compiler internal data
structures be dynamic so the capacity is exceeded only when there's not
enough memory.

>> The program I posted upthread was:
>>
>> int main(void) {
>> int obj = 42;
>> typedef void func(void);
>> if (0) {
>> func *fptr = (func*)&obj;
>> fptr();
>> }
>> }
>>
>> I assert that a conforming hosted implementation must successfully
>> translate and execute it (it has no visible runtime behavior other
>> than returning a successful status) subject to capacity limits.
>> An implementation is no more or less permitted to reject it than
>> it is to reject "hello, world".
>
> I can agree that a conforming implementation is required to accept that
> code, whatever it is that "accept" means - your conclusion follows from
> your beliefs about what "accept" means. For myself, I believe that after
> accepting such code, a fully conforming implementation can then fail to
> translate and execute that code, due to it exceeding that
> implementation's capacity.

Sure, capacity is not clearly defined, and is explicitly outside the
scope of the standard. But no real compiler is going to run out of
resources trying to compile that 8-line program. My whole point is
that, in my opinion, a compiler may not use the conversion from int* to
func* as a justification for rejecting it. Capacity limits, interesting
as they are, are a distraction from the point I was making with that
program.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

In article <uhfija$249ng$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>It has been decades since the first time I saw someone point out that
>"accept" is not defined by the standard, with active committee members
>participating in the discussion. I have to accept that the committee
>does not feel that this is a flaw urgently in need of correction - which
>I consider a mistake by the committee.
>
>> I suggest that "accept" *does* (or at least should) mean "successfully
>> translate and execute".

But if they did that (defined "accept" as shown above), then wouldn't they
then have to define "successfully", "translate", and "execute"?

And so on, and so on...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RepInsults

On 2023-10-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uhfija$249ng$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> ...
>>It has been decades since the first time I saw someone point out that
>>"accept" is not defined by the standard, with active committee members
>>participating in the discussion. I have to accept that the committee
>>does not feel that this is a flaw urgently in need of correction - which
>>I consider a mistake by the committee.
>>
>>> I suggest that "accept" *does* (or at least should) mean "successfully
>>> translate and execute".
>
> But if they did that (defined "accept" as shown above), then wouldn't they
> then have to define "successfully", "translate", and "execute"?

It depends. Translate is what the implementation does; it has
translation phases. So it can be understood from that.

Successfully is nuanced, and could benefit from a definition:

successful execution: performance of all requirements in relation to
the semantics of a specific, strictly conforming program,
uninterrupted by an abrupt termination. Note that this concept is
independent of the termination status of the program; a program
whose termination status is unsuccessful is successfully executed
if it passes that point whereupon it indicates that termination status
to the host environment.

Someone should write a program which tabulates all words used in the
standrad, and then go through them one by one, identifying which ones
need a definition.

The standard should also cite a specific edition of a specific
English-language dictionary, as the source of definitions of words
that are not defined in the document, or in that ridiculous ISO 2382-1.

Speaking of which, ISO 2382-1 is replete with embarassing drivel; it
should be discontinued as a normative reference. You will never find a
satisfying answer to any matter of terminology in that reference;
I suspect that including might just some boilerplate imposed by ISO.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/27/23 04:53, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> And as a result of the way that the standard expressed those
>> requirements, an implementation could have capacity limits that prevent
>> it from translating and executing any program other than the "one
>> program" that it's required to translate and execute, without failing to
>> conform to the standard.
>
> Yes, of course. A very perverse implementation could detect the "one
> program" and generate code for it (the "one program" might print "hello,
> world", for example), and print a fatal capacity error for anything
> else. I've been tempted to create such an implementation myself.
> (Yes, I have odd ideas of fun.)

Now that I'm retired, I've actually started working on such an
implementation. I call it MinimalC. I decided to make it a more
interesting project by including support for multiple different versions
of the C standard, starting with C90. I decided to use it as an excuse
to get familiar with several development tools that I didn't have much
time to learn while I was employed, such as flex, bison, Doxygen,
BibTeX, and the Eclipse IDE, as well as the new Unicode support provided
by recent versions of C and C++. While I've used SVN before, this is the
first time I've been the person who sets up SVN. I'm learning a lot. I'm
also getting stuck a lot - but nothing depends upon me meeting a
schedule anymore.
However, due to taking care of twin 8-year olds and being a househusband
while my (younger) wife continues working, I've found that my retirement
doesn't leave me with anywhere near as much free time as I'd hoped.
Don't hold your breath waiting for me to release MinimalC.

On 2023-10-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uhfija$249ng$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> ...
>>It has been decades since the first time I saw someone point out that
>>"accept" is not defined by the standard, with active committee members
>>participating in the discussion. I have to accept that the committee
>>does not feel that this is a flaw urgently in need of correction - which
>>I consider a mistake by the committee.
>>
>>> I suggest that "accept" *does* (or at least should) mean "successfully
>>> translate and execute".
>
> But if they did that (defined "accept" as shown above), then wouldn't they
> then have to define "successfully", "translate", and "execute"?

The meaning of "translate" is implicitly adequately defined by the
translation phases section. The meaning of "execute" is adequately clear
from the semantics sections is part 6 and 7. Of those phrases, "accept"
is the only problematic one.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> The point isn't quite the same. The C standard explicitly says
>>>> integers may be converted to any pointer type. The C standard
>>>> does not say that a pointer to an object type may be converted
>>>> to a pointer to function type. Every implementation is within
>>>> its rights to reject any program whose static text includes[*] a
>>>> cast from a pointer to an object type to a pointer to function
>>>> type, regardless of whether the cast has any chance of being
>>>> executed.
>>>>
>>>> [*] meaning, still present as source of any preprocessor
>>>> conditionals have been processed, etc.
>>>
>>> I disagree. (I think we've discussed this before.)
>>>
>>> Concretely, I believe that this program violates no syntax error
>>> or constraint. It includes code whose behavior would be undefined
>>> if it were executed, but the `if (0)` prevents that.
>>>
>>> On what basis do you think a conforming implementation may reject
>>> it?
>>
>> First let me ask a question. Does the C standard allow an
>> implementation to reject any program that is not strictly
>> conforming?
>
> [...]
>
> The standard never talks about rejection. It requires that "A
> conforming hosted implementation shall accept any strictly
> conforming program.". No such requirement applies to any program
> which is not strictly conforming. (4p6)

Perhaps I shouldn't have used the word "reject". If the question
were phrased "Does the C standard allow an implementation not to
accept any program that is not strictly conforming?", does your
comment above mean you would say Yes to that question?

Richard Damon <richard@damon-family.org> writes:

> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> The point isn't quite the same. The C standard explicitly says
>>>> integers may be converted to any pointer type. The C standard
>>>> does not say that a pointer to an object type may be converted
>>>> to a pointer to function type. Every implementation is within
>>>> its rights to reject any program whose static text includes[*] a
>>>> cast from a pointer to an object type to a pointer to function
>>>> type, regardless of whether the cast has any chance of being
>>>> executed.
>>>>
>>>> [*] meaning, still present as source of any preprocessor
>>>> conditionals have been processed, etc.
>>>
>>> I disagree. (I think we've discussed this before.)
>>>
>>> Concretely, I believe that this program violates no syntax error
>>> or constraint. It includes code whose behavior would be undefined
>>> if it were executed, but the `if (0)` prevents that.
>>>
>>> On what basis do you think a conforming implementation may reject
>>> it?
>>
>> First let me ask a question. Does the C standard allow an
>> implementation to reject any program that is not strictly
>> conforming?
>
> No, to reject a program it must violate some constraint.
>
> Not being 'strictly conforming' (a technical term in the Standard)
> is not a requirement for a program to be accepted.

In 4p6 the C standard says conforming implementations shall
accept any strictly conforming program. (There are some minor
differences between hosted implementations and freestanding
implementations but that's not important to the question.)
Does the C standard make any other statement about what programs
must be accepted? If so where are those statements? If not,
what is the basis for your statement that for an implementation
to reject a program the program must violate some constraint?

I'm assuming by the way that "reject" is being read as the
opposite of "accept", which is how I meant it: an implementation
rejects a program if and only if the implementation doesn't
accept the program. Come to think of it, "decline" might be a
better word choice for the opposite of "accept". Either way
though, the principle is that a program is either "accepted"
or "not accepted"; these is nothing in between.

(I should add that it is possible that a failure could occur
before an implementation could tell whether it would accept it or
not. I think it's logically consistent to count such cases as
accepted: if the program turns out to be strictly conforming,
the implementation has accepted it, and if the program turns out
to have an unskipped #error directive, the implementation has not
successfully translated it. So the requirements of the standard
are satisfied.)

> Now, there is the escape clause, that allows an implementation to
> fail to actually be able to run anything but the one specified
> program that meets all the minimum requirements, but that isn't
> grounds to 'reject' programs.

Accepting a program has nothing to do with actually running the
program; producing an executable is enough. Trying to produce
an executable but not succeeding because of one of the factors
mentioned in section 1 paragraph 2 still counts as accepting.

Implementation limits (as the term is used in the C standard)
fall in a different category. The standard requires an
implementation to accept a program if the program is strictly
conforming, but a program is not considered strictly conforming
if it exceeds a minimum implementation limit. Consider this
source file:

int one =
((((((((((((((((((((((((((((((((((((((((((((((((((
((((((((((((((((((((((((((((((((((((((((((((((((((
1
))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))
;

Can an implementation decline to translate this source file (and
so not accept it) and still be conforming? There are 100 nested
levels of parentheses.

Or consider this source file:

extern char big[ 2305843009213693952 ];

Can an implementation decline to translate this source file (and
so not accept it) and still be conforming? (The value of SIZE_MAX
may be assumed to be 2**64-1.)

For both of these questions, it may be assumed that the concerns
mentioned in 1p2 do not affect the answers.

On 2023-10-29, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
>
>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>>
>>> Keith Thompson <Keith.S.T...@gmail.com> writes:
....
>>>> Concretely, I believe that this program violates no syntax error
>>>> or constraint. It includes code whose behavior would be undefined
>>>> if it were executed, but the `if (0)` prevents that.
>>>>
>>>> On what basis do you think a conforming implementation may reject
>>>> it?
>>>
>>> First let me ask a question. Does the C standard allow an
>>> implementation to reject any program that is not strictly
>>> conforming?
>>
>> [...]
>>
>> The standard never talks about rejection. It requires that "A
>> conforming hosted implementation shall accept any strictly
>> conforming program.". No such requirement applies to any program
>> which is not strictly conforming. (4p6)
>
> Perhaps I shouldn't have used the word "reject". If the question
> were phrased "Does the C standard allow an implementation not to
> accept any program that is not strictly conforming?", does your
> comment above mean you would say Yes to that question?

As I said. and you quoted above, "No such requirement applies to any
program which is not strictly conforming". That means that "there is no
requirement to accept" or in other words "it is allowed to not accept",
or in other words "it is allowed to reject". How could I have reworded
that comment to render it unnecessary for you to ask the above question,
and why would such re-wording have been necessary?

The key point is that the code in question is strictly conforming, and a
implementation therefore IS required to accept it.

You earlier claimed "Every implementation is within its rights to reject
any program whose static text includes[*] a cast from a pointer to an
object type to a pointer to function type, regardless of whether the
cast has any chance of being executed." Since ensuring that such code
might not get executed is sufficient to make the program strictly
conforming (DR 109), and this code guarantees that it won't be executed,
how can an implementation be within it's rights to reject it?

On 27/10/2023 17:35, James Kuyper wrote:
> However, due to taking care of twin 8-year olds and being a househusband
> while my (younger) wife continues working, I've found that my retirement
> doesn't leave me with anywhere near as much free time as I'd hoped.
> Don't hold your breath waiting for me to release MinimalC.

James, my wife quit before I did (and acted as project manager for our
house, which needed lots of work. Our house is older than your country).

We have no grandchildren.

And yet still I don't have free time. I've got a lot fitter though, and
the garden is much neater!

Andy

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>> The point isn't quite the same. The C standard explicitly says
>>>>> integers may be converted to any pointer type. The C standard
>>>>> does not say that a pointer to an object type may be converted
>>>>> to a pointer to function type. Every implementation is within
>>>>> its rights to reject any program whose static text includes[*] a
>>>>> cast from a pointer to an object type to a pointer to function
>>>>> type, regardless of whether the cast has any chance of being
>>>>> executed.
>>>>>
>>>>> [*] meaning, still present as source of any preprocessor
>>>>> conditionals have been processed, etc.
>>>>
>>>> I disagree. (I think we've discussed this before.)
>>>>
>>>> Concretely, I believe that this program violates no syntax error
>>>> or constraint. It includes code whose behavior would be undefined
>>>> if it were executed, but the `if (0)` prevents that.
>>>>
>>>> On what basis do you think a conforming implementation may reject
>>>> it?
>>>
>>> First let me ask a question. Does the C standard allow an
>>> implementation to reject any program that is not strictly
>>> conforming?
>>
>> [...]
>>
>> The standard never talks about rejection. It requires that "A
>> conforming hosted implementation shall accept any strictly
>> conforming program.". No such requirement applies to any program
>> which is not strictly conforming. (4p6)
>
> Perhaps I shouldn't have used the word "reject". If the question
> were phrased "Does the C standard allow an implementation not to
> accept any program that is not strictly conforming?", does your
> comment above mean you would say Yes to that question?

I've decided not to answer any more of your questions until you
answer mine.

The code we're discussing was snipped at some point, so here it
is again:

int main(void) {
int obj = 42;
typedef void func(void);
if (0) {
func *fptr = (func*)&obj;
fptr();
}
}

It illustrates the issue that the standard does not define the behavior
of a conversion from an object pointer type to a function pointer type
(other than the special case of a null pointer constant), but does not
make such conversion, expressed as a cast, a constraint violation.

I asked: "On what basis do you think a conforming implementation may
reject it? Do you see a syntax rule or constraint that it violates? Do
you see some other basis for rejecting it?"

To be clear, I'm asking about whether an implementation may reject it
specifically because of the pointer conversion, not about reasons for
rejecting it that would apply equally to a "hello, world" program.

Feel free to disregard the following paragraphs.

The impression I get (very likely a wrong one) is that you are
trying to use a Socratic method, asking me questions that you
think will steer me to the correct conclusion -- a conclusion that
you have not shared. I am not speculating about your motivations
(which you hide very well); rather, I am letting you know about the
impression that I get from what you write. I'm interested in what
you think about relevant technical issues, but I'm not interested
in playing the role of your student.

(We have two similar discussions happening in parallel in different
threads. The other one involved a non-void function falling off
the end, with the caller attempting to use the result. I won't get
into that code in this thread, other than to say that I'm awaiting
your answer there as well. In both threads, it's becoming difficult
to remember what was being discussed in the first place.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/25/23 02:46, Kaz Kylheku wrote:
>>> On 2023-10-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>
>>>> The standard never talks about rejection. It requires that "A
>>>> conforming hosted implementation shall accept any strictly
>>>> conforming program.". No such requirement applies to any program
>>>> which is not strictly conforming. (4p6) [...]
>>>
>>> What does "accept" mean? I don't see it defined. ...

I would like to address the meaning of "accept". Please bear with
me as I work through excerpts from two postings, the second one
the grandchild of this first one. (Some text may be pruned or
reordered, but I have made an effort to keep the attributions
intact and correct.)

The term "accept" is commonly used in the field of automata theory.
It means something like "to admit as satisfying the criteria" of the
automata in question. For example, if an automata to determine
primality accepts an input it means the input is a prime number.
This sense of accept is close to what the C standard means.

>> Correct. In the absence of a standard-defined meaning, we're left
>> with the ordinary English meaning of the word. Since I can accept
>> a gift without, in any way, being obligated to do anything with it,
>> I've argued that a implementation could meet that requirement by
>> issuing the message "Program accepted", and doing nothing else with
>> it. The message, not being a mandatory diagnostic, is optional.

It's more likely that the ISO C committee meant "accept" in some
more technical sense (probably similar to the usage explained above)
than in the sense of an ordinary English meaning.

>> The ordinary English meaning of accept is opposite to the meaning of
>> reject (which is neither defined nor even used in the standard). As
>> such, citing the text requiring strictly conforming code to be
>> accepted, is as close as I can come to supporting Keith's skepticism
>> about a conforming implementation being allowed to reject this code.

The word "accept" has lots of antonyms: deny, veto, snub, shun,
spurn, demur, reject, refuse, resist, rebuff, oppose, decline,
dismiss, disallow, renounce, repudiate, blackball, and disapprove
are just some of the dozens of easily findable antonyms. Looking
over the list, I think a better opposite word is not "reject" but
"dismiss", which suggests these definitions:

accept: admit as suitable for translation (by this implementation)
(opposite): dismiss as unsuitable for translation (by this implementation)

These definitions provide a good fit to how the word "accept" is
used in the C standard, including other parts of the standard that
talk about translation or execution but don't use the word "accept"
explicitly.

Note in particular that "accept" is a prerequisite for translation,
not the other way around, which is consistent with how the standard
uses these terms.

>>> [it seems inconsistent for "accept" to mean "successfully
>>> translate and execute"]
>>
>> I fully agree. Whatever "accept" means, it must be something less
>> strong than "translate and execute".
>
> I don't agree (though I do agree that the standard is unclear on
> what it means).
>
> I don't think that printing "Program accepted" and doing nothing
> else would satisfy the standard's requirements. [...]

This statement implicitly offers a false dichotomy. What "accept"
means can be less stringent than "translate and execute" but still
imply more than just printing a "program accepted" message.

> I suggest that "accept" *does* (or at least should) mean
> "successfully translate and execute".

Obviously this statement cannot be right. For one thing, it's not
possible. Perhaps more to the point, it is well established that
the C standard allows an implementation to be conforming even if
it can translate and execute only one program. There were heated
debates on the topic when the original C standard was formed. The
meaning of "accept" needs to be determined by what the standard
actually says about its requirements, not what we might want it to
say.

> The standard does not specify "the size or complexity of a program
> and its data that will exceed the capacity of any specific
> data-processing system or the capacity of a particular processor"
> (Scope, section 1 paragraph 2) -- so *some* programs will exceed
> an implementation's capacity.
>
> 5.2.4.1 says that "The implementation shall be able to translate
> and execute at least one program that contains at least one
> instance of every one of the following limits". That imposes a
> restriction on an implementation's capacity limits. (And it does
> it in a way that's straightforwardly specified, but such that the
> easiest non-perverse way to conform is to have *reasonable*
> capacity limits.)

These paragraphs confuse several distinct notions and entities. The
term "limits" is used (in many places) in relation to implementations.
The term "capacity" appears in the standard exactly twice, once in
relation to a data-processing system, and once in relation to a
processor. The compound term "capacity limits" is never used. The
last item in 1p2

[the standard does not specify] all minimal requirements of a
data-processing system that is capable of supporting a conforming
implementation.

makes it clear that "implementations" and "data-processing systems"
are two different things (and of course processors occupy yet a third
category). This distinction makes sense: if I run gcc on my colo
server (which has 1GB of RAM), or if I run gcc on my compute server
(which has 128GB of RAM), in both cases the implementation is gcc (and
glibc or similar); it is only the underlying data-processing system
that is different.

> [...]
>
> My reading of all that is that a conforming implementation must
> translate and execute any *correct* program and any *strictly
> conforming* program **that does not exceed its capacity limits**.

Implementations have implementation limits (described in many places
in the standard). Data-processing systems (and also processors) have
capacities, about which the standard has nothing to say, not even
implicitly. The compound phrase "capacity limits" is meaningless.

[and now on to the second message]

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/26/23 03:10, Keith Thompson wrote:

>>> I suggest that "accept" *does* (or at least should) mean
>>> "successfully translate and execute".
>>
>> If the "one program" for a given implementation of C is strictly
>> conforming, that would render 5.2.4.1 redundant.
>> If the "one program" is not strictly conforming, then 5.2.4.1
>> serves merely to mandate something for one program which was not
>> strictly conforming, which was already mandated for all strictly
>> conforming ones.
>
> My interpretation (perhaps not fully supported by the wording of
> the standard) is that the requirement to accept any strictly
> conforming program is conditional on that program not exceeding
> the implementation's capacity.

A. It isn't. The standard means what it says. It's up to us to
find a definition for "accept" that's consistent with what the C
standard does say, not with what we think it ought to say. The
definitions I gave above for "accept" and "dismiss" (meant as
opposite to accept) are consistent with what the standard actually
says, without any problem from what might occur when an attempt is
made to translate a program.

B. Perhaps a better way to understand what "accept" means is to
look at its opposite. This program

int
main(void){
return (((0)));
}

must be accepted (that is, an implementation must deem it suitable
for translation, and attempt to translate it), because it is
strictly conforming. The attempt to translate is key. On the
flip side, this program

int
main(void){
return
((((((((((((((((((((((((((((((((((((((((((((((((((
((((((((((((((((((((((((((((((((((((((((((((((((((
0
))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))
;
}

does not have to be accepted (it isn't strictly conforming, because
it exceeds a minimum implementation limit). An implementation is
free to dismiss the program as being unsuitable for translation (by
that implementation), by virtue of not meeting all the requirements
for a strictly conforming program.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 2023-10-29, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>>>
>>>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>
> ...
>
>>>>> Concretely, I believe that this program violates no syntax
>>>>> error or constraint. It includes code whose behavior would be
>>>>> undefined if it were executed, but the `if (0)` prevents that.
>>>>>
>>>>> On what basis do you think a conforming implementation may
>>>>> reject it?
>>>>
>>>> First let me ask a question. Does the C standard allow an
>>>> implementation to reject any program that is not strictly
>>>> conforming?
>>>
>>> [...]
>>>
>>> The standard never talks about rejection. It requires that "A
>>> conforming hosted implementation shall accept any strictly
>>> conforming program.". No such requirement applies to any program
>>> which is not strictly conforming. (4p6)
>>
>> Perhaps I shouldn't have used the word "reject". If the question
>> were phrased "Does the C standard allow an implementation not to
>> accept any program that is not strictly conforming?", does your
>> comment above mean you would say Yes to that question?
>
> As I said. and you quoted above, "No such requirement applies to
> any program which is not strictly conforming". That means that
> "there is no requirement to accept" or in other words "it is
> allowed to not accept", or in other words "it is allowed to
> reject". How could I have reworded that comment to render it
> unnecessary for you to ask the above question,

Give a direct answer: "I believe the intent of the C standard
allows an implementation not to accept any program that is not
strictly conforming. (When you say reject I'm assuming you
mean the opposite of accept.)" Just those two sentences, and
nothing more.

> and why would such re-wording have been necessary?

First, because I wasn't sure after reading your long answer
whether you might have been trying to make some subtle
distinction between the question I asked and the answer you were
giving.

Second, the purpose of posing the question I asked was to make
sure there is consensus on the threshold question. I think it's
important to focus on this issue while it is still being debated.
I expect you have observed that of the four people responding, two
have agreed (you and Kaz) and two have not agreed (Richard Damon
and Keith Thompson). I posted a followup question in response to
Richard's answer, but he has not yet replied. Keith's comments
have been the most emphatic in disagreeing, and I think it would
help to discuss the threshold question separately before we get to
the larger question, so the discussion doesn't get too confused.

Third, considering the two previous points, giving a short direct
answer as outlined above is important to eliminate the need for me
to respond and try to narrow the focus to just the threshold
question. I know the larger issue is important to you, and we
should get back to it, but I ask this question first because it's
important to what I have to say later. Trying to take two steps
at a time often leads to confusion, especially in the context of a
discussion in comp.lang.c.

> The key point is that the code in question is strictly conforming,
> and a implementation therefore IS required to accept it.

Before I explain why that isn't so I really think it would help to
make sure everyone is on the same page with respect to the threshold
question, because if someone doesn't agree that the standard allows
a conforming implementation to reject any program that isn't
strictly conforming there is no point trying to explain to them
further.

> You earlier claimed "Every implementation is within its rights to
> reject any program whose static text includes[*] a cast from a
> pointer to an object type to a pointer to function type,
> regardless of whether the cast has any chance of being executed."
> Since ensuring that such code might not get executed is sufficient
> to make the program strictly conforming (DR 109), and this code
> guarantees that it won't be executed, how can an implementation be
> within it's rights to reject it?

Your reasoning is fine as far as it goes, but it's incomplete. I
still would like to reach a shared understanding about the threshold
question. I just posted a reply earlier today to two of Keith's
postings on this, let's give him a chance to respond before going
further.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> The point isn't quite the same. The C standard explicitly says
>>>> integers may be converted to any pointer type. The C standard
>>>> does not say that a pointer to an object type may be converted
>>>> to a pointer to function type. Every implementation is within
>>>> its rights to reject any program whose static text includes[*] a
>>>> cast from a pointer to an object type to a pointer to function
>>>> type, regardless of whether the cast has any chance of being
>>>> executed.
>>>>
>>>> [*] meaning, still present as source of any preprocessor
>>>> conditionals have been processed, etc.
>>>
>>> I disagree. (I think we've discussed this before.)
>>>
>>> Concretely, I believe that this program violates no syntax
>>> error or constraint. It includes code whose behavior would
>>> be undefined if it were executed, but the `if (0)` prevents
>>> that.
>>>
>>> On what basis do you think a conforming implementation may
>>> reject it?
>>
>> First let me ask a question. Does the C standard allow an
>> implementation to reject any program that is not strictly
>> conforming?
>
> Not just for that reason.
>
> This program:
>
> #include <stdio.h>
> int main(void) {
> printf("%zu\n", sizeof (int));
> }
>
> is not strictly conforming, since it depends on the
> implementation-defined size of int. A hosted implementation
> that rejected it would violate 4p3:
>
> A program that is correct in all other aspects, operating
> on correct data, containing unspecified behavior shall be a
> correct program and act in accordance with 5.1.2.3.

We have talked before about 4p3. Your understandings of the
meaning and consequences of this sentence are mistaken, which if
you would take the time to read the published discussion notes
that led up to it being added to the standard I expect you would
realize. In any case 4p3 is moot, because we are addressing the
qualifying condition: if an implementation has a legitimate
reason not to accept a given program, then that program is not
"correct in all other aspects", and 4p3 doesn't apply.

Let's consider a concrete example. This program

#include <stdio.h>
#include <stdint.h>

extern char large[2305843009213693952];

int
main( void ){
printf( "Hello, world\n" );
printf( "\n" );
printf( "SIZE_MAX is %21zu\n", SIZE_MAX );
printf( " large has %21zu bytes\n", sizeof large );
printf( "\n" );
printf( "(... that's all, folks! ...)\n" );
return 0;
}

is, if I am not mistaken, free of any undefined behavior. It can
be compiled and run, for example by gcc on a 64-bit linux system.
Yet if we ask clang to compile it on the same system, clang gives
an error complaining that the array is too large. Note that the
same program, except with a one-smaller value of the array
dimension, can be compiled by clang without complaint, and run
successfully. Clearly the clang implementors feel that the C
standard allows them not to accept this program, and the only
reason I can see for that is that the program is not strictly
conforming, because it exceeds a minimum implementation limit.

Long story short: in how it treats this program, clang agrees
with my reading of the C standard. Incidentally, gcc has the
same behavior as clang, only with a larger value of the array
dimension.

> (A perverse implementation could claim that it exceeds its
> capacity, but I think we can ignore that.)

Per the C standard, "capacity" applies to data-processing systems
or to processors, not implementations. Implementations have
implementation limits, also referred to in the standard as
environmental limits or translation limits.

> What is your answer to your own question?

The C standard requires implementations to accept any strictly
conforming program. There is no statement in the standard that
requires implementations to accept any program other than those
that are strictly conforming (except perhaps the "one program"
of 5.2.4.1 p1, but implementations are free to choose a strictly
conforming program to satisfy this requirement, so there is no
conflict there). Hence the C standard allows implementations not
to accept any program that is not strictly conforming.

> And I hope we're not going to go back and forth too many times
> before you answer mine.

Having a shared understanding on this threshold question is a
necessary prerequisite to addressing the larger question. If you
can't or won't agree that not being strictly conforming is by
itself sufficient basis for not accepting a program, then there
seems little point in continuing, as my answer depends on that
premise for its conclusion.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> [...]
>>>>>
>>>>>> The point isn't quite the same. The C standard explicitly says
>>>>>> integers may be converted to any pointer type. The C standard
>>>>>> does not say that a pointer to an object type may be converted
>>>>>> to a pointer to function type. Every implementation is within
>>>>>> its rights to reject any program whose static text includes[*] a
>>>>>> cast from a pointer to an object type to a pointer to function
>>>>>> type, regardless of whether the cast has any chance of being
>>>>>> executed.
>>>>>>
>>>>>> [*] meaning, still present as source of any preprocessor
>>>>>> conditionals have been processed, etc.
>>>>>
>>>>> I disagree. (I think we've discussed this before.)
>>>>>
>>>>> Concretely, I believe that this program violates no syntax
>>>>> error or constraint. It includes code whose behavior would be
>>>>> undefined if it were executed, but the `if (0)` prevents that.
>>>>>
>>>>> On what basis do you think a conforming implementation may
>>>>> reject it?
>>>>
>>>> First let me ask a question. Does the C standard allow an
>>>> implementation to reject any program that is not strictly
>>>> conforming?
>>>
>>> [...]

Let me respond now to the paragraph below, and get back to your
other comments in a later posting.

> The impression I get (very likely a wrong one) is that you are
> trying to use a Socratic method, asking me questions that you
> think will steer me to the correct conclusion -- a conclusion that
> you have not shared. I am not speculating about your motivations
> (which you hide very well); rather, I am letting you know about the
> impression that I get from what you write. I'm interested in what
> you think about relevant technical issues, but I'm not interested
> in playing the role of your student.

To be clear, my question above is meant to elicit your views on
what I asked about. My question was not meant to educate you, to
be a Socratic question, or to steer you in any particular
direction. I was only looking for an answer, nothing more.

I ask the question because it is a threshold question for your
earlier question upthread. My answer to your prior question
depends on this premise for its conclusion. I asked my question
separately because I want to clarify the discussion. As things
stand, my question has gotten a yes answer from James Kuyper and
Kaz, and a no answer from Richard Damon and yourself. I
responded to Richard's posting sometime last week but have not
seen any followup from him on that. I responded to several of
your postings just in the last day, so I'm not sure if you have
had a chance yet to read those. If after reading my comments you
agree that the C standard allows implementations not to accept
any program that is not strictly conforming then I can go ahead
and answer your question. If after reading my comments you still
do not agree to that premise then there really isn't anything
more for me to say other than I believe your understanding of the
C standard is not consistent with what its authors intend. I can
agree to accept (no pun intended) either view as your final
opinion on the matter.

> James Kuyper <james...@alumni.caltech.edu> writes:
>
>> On 2023-10-29, Tim Rentsch wrote:
>>
>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>
>>>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
....
>>>>> First let me ask a question. Does the C standard allow an
>>>>> implementation to reject any program that is not strictly
>>>>> conforming?
>>>>
>>>> [...]
>>>>
>>>> The standard never talks about rejection. It requires that "A
>>>> conforming hosted implementation shall accept any strictly
>>>> conforming program.". No such requirement applies to any program
>>>> which is not strictly conforming. (4p6)
>>>
>>> Perhaps I shouldn't have used the word "reject". If the question
>>> were phrased "Does the C standard allow an implementation not to
>>> accept any program that is not strictly conforming?", does your
>>> comment above mean you would say Yes to that question?
>>
>> As I said. and you quoted above, "No such requirement applies to
>> any program which is not strictly conforming". That means that
>> "there is no requirement to accept" or in other words "it is
>> allowed to not accept", or in other words "it is allowed to
>> reject". How could I have reworded that comment to render it
>> unnecessary for you to ask the above question,
>
> Give a direct answer: "I believe the intent of the C standard
> allows an implementation not to accept any program that is not
> strictly conforming. (When you say reject I'm assuming you
> mean the opposite of accept.)" Just those two sentences, and
> nothing more.

There's several problems with that formulation, which is why I didn't
use it:
1. "I believe" implies either uncertainty, or that I consider it to be a
matter of opinion, not a matter of fact. Neither of those apply in this
context.

2. "the intent of the C standard" - the C standard is a document; it is
the C committee which had an intent, not the standard itself - but
that's a nitpick.
I'm primarily interested in what the standard actually says. I've an
interest in what the intent was only to the extent that I believe that
the standard fails to correctly reflect the committee's intent. In that
case the intent is valuable for determining how the standard needs to be
corrected to express that intent. I don't think that's applicable in
this context.

My statement was that, as a matter of fact, not an opinion, the C
standard allows an implementation to not accept a program that is not
strictly conforming, by the simple expedient of making the only
requirement that a program be accepted dependent on it being strictly
conforming.

There is uncertainty and room for differences of opinion about the
meaning of "accept"- but I don't see that uncertainty as being relevant
to Keith's original question. Unless the definition of "accept" is so
weird that it includes rejecting the program, Keith's point stands. As
far as I know, no one has proposed a definition for "accept" that is
that weird.

>> and why would such re-wording have been necessary?
>
> First, because I wasn't sure after reading your long answer
> whether you might have been trying to make some subtle
> distinction between the question I asked and the answer you were
> giving.

I was, and quite explicitly so. The key distinction is that the standard
only talks about acceptance, while Keith's question and yours were about
rejection. However, unless your definition of "accept" is so weird that
and implementation could simultaneously be said to have accepted and
rejected a program, that clause prohibits rejecting this strictly
conforming code.

> Second, the purpose of posing the question I asked was to make
> sure there is consensus on the threshold question. ...

I don't see why - what evidence is there that anyone fails to have
consensus on that point? Everyone who's claimed that such code cannot be
rejected has explicitly said that it was because they believe the code
is strictly conforming. No one has suggested that it fails to be
strictly conforming, but still cannot be rejected.

> ... I think it's
> important to focus on this issue while it is still being debated.
> I expect you have observed that of the four people responding, two
> have agreed (you and Kaz) and two have not agreed (Richard Damon
> and Keith Thompson).

The situation is not as simple as agreement or disagreement. Kaz appears
to agree that strictly conforming code must be accepted, but expresses
extreme agnosticism about what "accept" means, which is pretty much in
agreement with me. He has, however, claimed (on 2023-10-03) that the
if(0) guaranteeing that the code does not get executed does not protect
the code from having undefined behavior, whereas I read the resolution
of DR 109 as indicating that it does protect it - the code mentioned in
DR 109 was far less well protected against execution than this code, and
was still strictly conforming.

Richard Damon claimed that rejecting a program requires a constraint
violation, which is incomplete. A program may also be rejected for a
syntax error or for having code that would have undefined behavior if
executed, if that it was guaranteed that the code would be executed if
the program were executed. DR 109 made it clear that unless the code is
guaranteed to be executed, the fact that it would have undefined
behavior if executed does not, in itself, allow rejection of the
program. Since his contribution was rather brief, and no one mentioned
those points in response to that message, I'm not sure whether leaving
those exceptions out was accidental.

Keith has some subtle disagreements with me about the meaning of the
word "accept" - I say it's unspecified, so the requirement could be met
just by issuing a message "Program Accepted" - he thinks the meaning is
unclear, but is intended to be much stronger than that. However, he
agrees with me that this code is strictly conforming, and that, as a
result, an implementation is not permitted to reject it.

I posted a followup question in response to
> Richard's answer, but he has not yet replied. Keith's comments
> have been the most emphatic in disagreeing, and I think it would
> help to discuss the threshold question separately before we get to
> the larger question, so the discussion doesn't get too confused.

Keith is the one who has, most emphatically, asserted that the reason it
cannot be rejected is because it is strictly conforming - how could your
"threshold question" come into play?

>> The key point is that the code in question is strictly conforming,
>> and a implementation therefore IS required to accept it.
>
> Before I explain why that isn't so I really think it would help to
> make sure everyone is on the same page with respect to the threshold
> question, because if someone doesn't agree that the standard allows
> a conforming implementation to reject any program that isn't
> strictly conforming there is no point trying to explain to them
> further.

But no one has said anything to justify having any doubts about whether
they would agree. It is the strict conformance of the code that they are
asserting, not a requirement to accept code that isn't strictly conforming.

>> You earlier claimed "Every implementation is within its rights to
>> reject any program whose static text includes[*] a cast from a
>> pointer to an object type to a pointer to function type,
>> regardless of whether the cast has any chance of being executed."
>> Since ensuring that such code might not get executed is sufficient
>> to make the program strictly conforming (DR 109), and this code
>> guarantees that it won't be executed, how can an implementation be
>> within it's rights to reject it?
>
> Your reasoning is fine as far as it goes, but it's incomplete. I
> still would like to reach a shared understanding about the threshold
> question. I just posted a reply earlier today to two of Keith's
> postings on this, let's give him a chance to respond before going
> further.

His last message that I've seen indicates that he will not respond until
you answer his question: ""On what basis do you think a conforming
implementation may reject it? Do you see a syntax rule or constraint
that it violates? Do you see some other basis for rejecting it?"

If you also refuse to answer his question until he answers yours, the
two of you are at an impasse. I consider his insistence on an answer to
be more reasonable than yours, because it is the directly relevant
question. I consider your insistence to be unreasonable, because nobody
has said anything to suggest disagreement with your threshold question.
In fact, we've tried (and apparently, in your eyes, failed, for reasons
that are unclear) to express basic agreement with it (subject to minor
quibble about the relationship between "accept" and "reject"). We only
disagree about it's applicability to this strictly conforming code.

On 2023-11-10, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Having a shared understanding on this threshold question is a
> necessary prerequisite to addressing the larger question. If you
> can't or won't agree that not being strictly conforming is by
> itself sufficient basis for not accepting a program, then there
> seems little point in continuing, as my answer depends on that
> premise for its conclusion.

But the following isn't strictly confroming:

int x = 65536;

do you think that an implementation whose int is 32 bits wide has
grounds for rejecting it because it's not strictly conforming?

We generally expect correct programs that make use of
implementation-defined characteristics to be translated.

The requirement to accept strictly conforming programs does not add up
to a blanket permission to reject non-strictly conforming programs.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-11-10, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Having a shared understanding on this threshold question is a
>> necessary prerequisite to addressing the larger question. If you
>> can't or won't agree that not being strictly conforming is by
>> itself sufficient basis for not accepting a program, then there
>> seems little point in continuing, as my answer depends on that
>> premise for its conclusion.
>
> But the following isn't strictly confroming:
>
> int x = 65536;
>
> do you think that an implementation whose int is 32 bits wide has
> grounds for rejecting it because it's not strictly conforming?
>
> We generally expect correct programs that make use of
> implementation-defined characteristics to be translated.
>
> The requirement to accept strictly conforming programs does not add up
> to a blanket permission to reject non-strictly conforming programs.

I think you are in effect asking two question. The first question
is does the C standard allow non-strictly-conforming code not to be
accepted, even if the code is reasonable for the system being
targeted? As I read the C standard, the answer to that question is
an unequivocal yes.

The second question is something like, is this a good idea?

Let me give a personal answer. It doesn't bother me that the C
standard allows such programs not to be accepted (with implied
clause, by conforming implementations). I say it doesn't bother me
in the same way that the C standard requires implementations to be
able to translate and execute only one program, and still be
conforming. No compiler worth using is going to reject the
statement 'int x = 65536;' on a 32-bit platform. Sure, the C
standard allows it, but nobody would use such a compiler, and it's
so much effort to write a C compiler that no one would do that,
except maybe as a joke. If that's what they want, more power to
them - it will be funny for about 5 minutes.

On the other hand, consider this statement

long pbits = 0240404242004042424254;

This statement compiles fine on my colo server, which runs linux,
and has 64-bit longs. But if I were to compile it on a system with
32-bit longs, the compiler is within its rights to say "oops, bad
program, I'm not going to translate this garbage". Personally I
view that behavior as a positive, so I'm glad the C standard allows
it.

The C standard deliberately sets a low bar. In practice the low
bar doesn't matter at all, because compiler writers want to produce
a useful, above and beyond what the C standard might require. And
in those cases like the 'long' assignment example above, there is a
benefit to compilers having the option to turn down the program.
The key phrase there is "having the option". Different people have
different requirements and want different behaviors. It's good
that the C standard recognizes that and allows a wide range of
choices, while still setting a reasonable bar for what programs
must be accepted.