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

>> 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-13 at 11:16, Tim Rentsch wrote:
....
> I don't see what it is you are hoping to accomplish with the
> above comments. Can you shed some light on that?

You quoted a lot of different comments that I made, for a variety of
different purposes. Since you quoted them all, am I correct in thinking
that you want reasons for all of them? That's what I'm going to assume.,
I would have thought that was obvious, but things involving discussions
with you seldom are. In the following explanation, I will terminate any
statement of fact with a parenthesized number. One of the things I'd
like to accomplish is to identify which of those statements you agree
with, which ones you disagree with, and the reasons for those
disagreements. Would you please respond by identifying by number the
ones you disagree with, and explain why?

Most fundamentally, what I an hoping to accomplish is to convince you to
answer Keith's question.

Since you have said you won't answer his question until he has answered
your "threshold question", and he won't answer that till you answer his,
I'm trying to convince you to abandon that requirement, on three grounds:

1. The question cannot be answered purely by reference to the standard
(1). Firstly because the standard never uses the word "reject" (2). The
closest the standard ever comes to addressing your question is 4p6 (3).
That clause relies upon the word "accept" (4). The standard never
provides a definition of "accept" (5). Therefore, until specific
meanings for both "accept" and "reject" are agreed upon, your question
cannot be answered (6).

2. However, unless those terms are defined in such a way that an
implementation can simultaneously accept and reject a program, 4p6 means
that the answer to your question is "yes" (7). I do not interpret those
words in a way that allows the answer to be "no". This is as close as I
or anyone else can reasonably come to agreeing with your assertion, but
you don't seem willing to accept it as an agreement. Keith has already
said much the same thing, with subtle differences in how he addresses
the ambiguities in the way those terms are defined. If you're waiting
for a fuller agreement from me, you won't get it - the words of the
standard don't allow me to do so. If you're waiting for Keith to agree
more fully, he's made it clear he's not willing to discuss this further
until you answer his question. If you're unwilling to bend on that
issue, there's no point in continuing this discussion.

3. You have no justification for thinking that disagreement on
"threshold question" is relevant to the disagreement. Everyone who has
said that the code cannot be rejected has said, or at least implied,
that it cannot be rejected because the code is strictly conforming(7).
If the code is strictly conforming, 4p6 guarantees that it must be
accepted (8). If you think that the code is not strictly conforming,
then that is the point that's in need of discussion, and we've been
waiting an unconscionably long time for you to start that discussion.

As a secondary matter, when I first cited 4p6 as the closest thing the
standard has to an answer to your question, you responded in a way that
indicated that you found my explanation unclear, for reasons that I find
unclear. I want to be able to make similar statements in the future in a
way that is clear enough from the beginning to not provoke such
questions. I asked you for suggestions for how I could have worded my
statement to achieve that goal, and you proposed alternative wording.
However, your proposal was unsuitable, saying and implying things that I
did not intend to say and imply. Your proposal does not clear up my own
uncertainty about why you found my statement unclear. One of the things
I'm hoping to accomplish is to enable clear communication with you. I
would appreciate getting a second suggestion, one that avoids the
problems I had with your first suggestion.

Let me put it this way: would it have been possible for me to invoke 4p6
as the closest thing that the standard has to an answer to your
question, without suggesting that I have any uncertainty about it's
relevance, without suggesting that it's relevance is a matter of
opinion, while referring only to what the standard actually says,
without invoking the intent of the committee when they wrote it?

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:
>>> 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.

Is your conclusion the same if the variable is scrapped and the printf
is given the type instead? clang retains its stance on the concept:

"""
phil@dovespaz:~$ clang -Wall -o crap crap.c
crap.c:11:59: error: array is too large (2305843009213693952 elements)
printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
^~~~~~~~~~~~~~~~~~~
1 error generated.
"""

Is there an "array", /per se/? I only see a type.

clang does seem to agree with me that it's a type it's looking at, as if
we try to feed it the expression-only version of sizeof, it notices that
you've given it a type name, not an expression:

"""
phil@dovespaz:~$ clang -Wall -o crap crap.c
crap.c:11:53: error: expected parentheses around type name in sizeof expression
printf( " large has %21zu bytes\n", sizeof char[2305843009213693952]);
^
( )
1 error generated.
"""

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Phil Carmody <pc+usenet@asdf.org> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>> 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.
>
> Is your conclusion the same if the variable is scrapped and the printf
> is given the type instead? clang retains its stance on the concept:
>
> """
> phil@dovespaz:~$ clang -Wall -o crap crap.c
> crap.c:11:59: error: array is too large (2305843009213693952 elements)
> printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
> ^~~~~~~~~~~~~~~~~~~
> 1 error generated.
> """
>
> Is there an "array", /per se/? I only see a type.

I'm not sure what distinction you're making.

I find it useful to think of "array" as an adjective, not a noun. Of
course there's no array *object* or array *expression* in
`sizeof(char[2305843009213693952]`. `char[2305843009213693952]` is
obviously an array *type*. There's no ambiguity here.

> clang does seem to agree with me that it's a type it's looking at, as if
> we try to feed it the expression-only version of sizeof, it notices that
> you've given it a type name, not an expression:
>
> """
> phil@dovespaz:~$ clang -Wall -o crap crap.c
> crap.c:11:53: error: expected parentheses around type name in sizeof expression
> printf( " large has %21zu bytes\n", sizeof char[2305843009213693952]);
> ^
> ( )
> 1 error generated.
> """

Yes, of course it's a type name. And?

--
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 */

Phil Carmody <pc+usenet@asdf.org> 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:
>>>
>>>> [...] Does the C standard allow an
>>>> implementation to reject any program that is not strictly
>>>> conforming?

[...]

>> 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.
>
> Is your conclusion the same if the variable is scrapped and the
> printf is given the type instead?

The short answer is yes.

The lower bound for SIZE_MAX is 65535. As I read the C standard,
any object or any type whose 'sizeof' is bigger than 65535 means
the program exceeds a minimum implementation limit, and is
therefore not strictly conforming. Because it is not strictly
conforming, implementations are free not to accept it.

> clang retains its stance on the concept:
>
> """
> phil@dovespaz:~$ clang -Wall -o crap crap.c
> crap.c:11:59: error: array is too large (2305843009213693952 elements)
> printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
> ^~~~~~~~~~~~~~~~~~~
> 1 error generated.
> """
>
> Is there an "array", /per se/? I only see a type.

An array type, but no array object. I think most people would say
there isn't an array, but just a type.

> clang does seem to agree with me that it's a type it's looking at,
> [...]

Right, the operand of that sizeof is syntactically a type, not an
expression (or more specifically, what the C standard calls a "type
name").

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

> On 2023-11-13 at 11:16, Tim Rentsch wrote:
> ...
>
>> I don't see what it is you are hoping to accomplish with the
>> above comments. Can you shed some light on that?
>
> [long response]

I want to address one part of what you said in your two last
postings, while I think about how to respond to other parts.

In an earlier posting, I wrote:

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.

When I say "the intent of the C standard", that is a stand-in for
a longer phrasing along the lines of "the intended meaning of the
C standard" or "the intent of the C standard's authors".

When I say "I believe ..." I mean it in the same way that I might
say "I believe the Riemann Hypothesis is true." That is, I am
making a statement about a question of fact, expressing a belief
about the answer to the question, without having proof or otherwise
convincing evidence.

To give a contrast, I do not mean "I believe ..." as addressing a
question of faith or a question of opinion. For example, "I believe
God exists" is a statement about a question of faith; answers to
questions of faith are unknowable, more or less by definition,
except by having faith.

Do you understand what I'm saying in those last three paragraphs?
Or is there something you're unsure about or find confusing?

When reading a statement or a question from someone, it's imporant
to understand what the writer thinks about what the statement or
question means. Similarly, when writing a statement or a question
for another person or persons, it's important to express what one
hopes to communicate in a way that will be understood by the
expected or intended audience as having the same meaning as what
the writer hopes to convey.

Does this last paragraph make sense? Would you say you agree with
it?

On 2023-11-14 at 12:03, Tim Rentsch wrote:
....
> I want to address one part of what you said in your two last
> postings, while I think about how to respond to other parts.
>
> In an earlier posting, I wrote:
>
> 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.
>
> When I say "the intent of the C standard", that is a stand-in for
> a longer phrasing along the lines of "the intended meaning of the
> C standard" or "the intent of the C standard's authors".

You could simply use "Committee", which is actually 1 character shorter
than "C standard". That removes length as a justification for using a
less accurate formulation.

> When I say "I believe ..." I mean it in the same way that I might
> say "I believe the Riemann Hypothesis is true." That is, I am
> making a statement about a question of fact, expressing a belief
> about the answer to the question, without having proof or otherwise
> convincing evidence.

If you lack proof or convincing evidence, it seems to me that you should
have uncertainty about the truth of the statement. If you do have such
uncertainty, that fits in with my own use of "I believe" to express
uncertainty.

I have what I consider adequate proof and convincing evidence for the
statement that you suggested I should prepend with "I believe". The
relevant evidence is the clause I cited from the standard. If you
consider my argument insufficiently convincing, you should be explaining
what flaws you see in my argument, rather than suggesting that I cover
those flaws by prefixing the statement with "I believe".

> To give a contrast, I do not mean "I believe ..." as addressing a
> question of faith or a question of opinion. For example, "I believe
> God exists" is a statement about a question of faith; answers to
> questions of faith are unknowable, more or less by definition,
> except by having faith.
>
> Do you understand what I'm saying in those last three paragraphs?
> Or is there something you're unsure about or find confusing?

I have adopted a different way of expressing myself precisely because I
consider the way you are expressing those things to be flawed. In
particular, I find it odd to prefix a perfectly ordinary statement of
fact with "I believe", if the intent is not to focus attention on the
fact that you believe it,rather than on the truth of the statement.
However, saying things that way is not sufficiently uncommon as to
seriously confuse me.

> When reading a statement or a question from someone, it's imporant
> to understand what the writer thinks about what the statement or
> question means. Similarly, when writing a statement or a question
> for another person or persons, it's important to express what one
> hopes to communicate in a way that will be understood by the
> expected or intended audience as having the same meaning as what
> the writer hopes to convey.
>
> Does this last paragraph make sense? Would you say you agree with
> it?

Yes, it does. And I frequently despair of ever figuring out a way to say
what I mean that will be understood as intended by you. Also you are far
too prone to making objections without bothering to explain them, as if
filling in those details is an exercise by the student. On those rare
occasions when I've discovered what the student was supposed to figure
out for himself, it's often been something I would never have figured
out - usually because of differences in the way you think about things.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Phil Carmody <pc+usenet@asdf.org> 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:
>>>>
>>>>> [...] Does the C standard allow an
>>>>> implementation to reject any program that is not strictly
>>>>> conforming?
>
> [...]
>
>>> 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.
>>
>> Is your conclusion the same if the variable is scrapped and the
>> printf is given the type instead?
>
> The short answer is yes.
>
> The lower bound for SIZE_MAX is 65535. As I read the C standard,
> any object or any type whose 'sizeof' is bigger than 65535 means
> the program exceeds a minimum implementation limit, and is
> therefore not strictly conforming. Because it is not strictly
> conforming, implementations are free not to accept it.

There's wording in the standard to support the "object" claim, but
I'm not seeing direct support for the "type" claim. Of course, there
might be a chain of deductions that leads there.

>> clang retains its stance on the concept:
>>
>> """
>> phil@dovespaz:~$ clang -Wall -o crap crap.c
>> crap.c:11:59: error: array is too large (2305843009213693952 elements)
>> printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
>> ^~~~~~~~~~~~~~~~~~~
>> 1 error generated.
>> """
>>
>> Is there an "array", /per se/? I only see a type.
>
> An array type, but no array object. I think most people would say
> there isn't an array, but just a type.

The standard uses the word "array" as a noun to refer to an array
object, so I was using the same usage as the standard there. And clang
was using that same word, and it was that usage of the word I was
calling into question. Given your similar view, I definitely think the
clang diagnostic is sloppily worded.

>> clang does seem to agree with me that it's a type it's looking at,
>> [...]
>
> Right, the operand of that sizeof is syntactically a type, not an
> expression (or more specifically, what the C standard calls a "type
> name").

Syntactically, yes.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Phil Carmody <pc+usenet@asdf.org> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Phil Carmody <pc+usenet@asdf.org> 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:
>>>>>
>>>>>> [...] Does the C standard allow an
>>>>>> implementation to reject any program that is not strictly
>>>>>> conforming?
>>
>> [...]
>>
>>>> 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.
>>>
>>> Is your conclusion the same if the variable is scrapped and the
>>> printf is given the type instead?
>>
>> The short answer is yes.
>>
>> The lower bound for SIZE_MAX is 65535. As I read the C standard,
>> any object or any type whose 'sizeof' is bigger than 65535 means
>> the program exceeds a minimum implementation limit, and is
>> therefore not strictly conforming. Because it is not strictly
>> conforming, implementations are free not to accept it.
>
> There's wording in the standard to support the "object" claim, but
> I'm not seeing direct support for the "type" claim. Of course, there
> might be a chain of deductions that leads there.

Here is my reasoning.

The sizeof operator works on both expressions (including expressions
that designate objects) and type names.

The result of sizeof has type size_t.

In <stdint.h>, the preprocessor symbol SIZE_MAX gives the maximum
value (for that implementation) of a value of type size_t. SIZE_MAX
has a lower bound of 65535 (a minimum implementation limit). So any
type whose size exceeds this value is violating the restriction that
strictly conforming programs not exceed a minimum implementation
limit. (Sorry if that was belaboring the obvious.)

Or, here is another way to look at it.

Implemenations are allowed to have size_t be a 16-bit type. If we
wanted to compile a declaration like

struct foo { char a[20000], b[20000], c[20000], d[20000]; };

on such an implementation, the implementation would have to refuse
the program, because the size cannot be represented in a 16-bit
size_t (types have sizes even if they are never an operand of a
sizeof expressions). Strictly conforming programs are intended to
be maximally portable. Because a program with a type whose size
is more than 65535 cannot be accepted by an implementation with
a 16-bit size_t, the program must not be strictly conforming.

>>> clang retains its stance on the concept:
>>>
>>> """
>>> phil@dovespaz:~$ clang -Wall -o crap crap.c
>>> crap.c:11:59: error: array is too large (2305843009213693952 elements)
>>> printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
>>> ^~~~~~~~~~~~~~~~~~~
>>> 1 error generated.
>>> """
>>>
>>> Is there an "array", /per se/? I only see a type.
>>
>> An array type, but no array object. I think most people would say
>> there isn't an array, but just a type.
>
> The standard uses the word "array" as a noun to refer to an array
> object, so I was using the same usage as the standard there.

Looking through the standard, I see that the word array is used both
as an adjective and as a noun.

> And clang
> was using that same word, and it was that usage of the word I was
> calling into question. Given your similar view, I definitely think the
> clang diagnostic is sloppily worded.

I am shocked, shocked to discover that a C compiler has a sloppily
worded diagnostic message.

But I agree with your assessment. :)

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

[...]

> (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. [...])

I don't remember any outstanding question from the discussion of
falling off the end of a non-void function. Looking back over
postings from you responding to a posting of mine I don't see
any either. I guess it's possible there was a question but I
didn't see it. In any case I have no idea what question in that
thread you want answered, so if you still want an answer please
ask the question again.

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

> Most fundamentally, what I an hoping to accomplish is to convince
> you to answer Keith's question.

Consider a C compiler for a machine where function pointers are
much bigger than any object pointer type. Functions might even
live in a completely different address space than data (a
so-called Harvard architecture). On such a machine there is no
sensible way to change an object pointer into a function pointer,
or vice versa. Naturally the compiler would prefer to choose not
to translate any source file that contains such a conversion.
The C standard doesn't say function pointers may be converted to
object pointers, or the other way around. The obvious thing to
do is simply give an error message and forego the translation
effort. It doesn't make sense that the standard would insist
that an implementation translate a construct that is nonsensical,
not just in a particular case but in every possible case.
Converting between function pointers and object pointers isn't
like dividing by zero.

An impediment to giving Keith an answer to his question is that
what he's looking for is not just a response but an argument.
That is, it's important that what I say not only be something he
understands but also something that convinces him. That isn't
easy because his ideas of what the C standard requires are so
weird. Keith's view of the standard is heavily influenced by
what he wants it to require, and that want often prevails over
the plain language of text in the standard. His reaction to the
idea that any non-strictly-conforming program may be rejected,
for example, or the idea that "accept" does or should mean a
program must be successfully translated and executed, are clearly
at odds with the plain language says about what programs must be
accepted. In a footnote the C standard says "Strictly conforming
programs are intended to be maximally portable among conforming
implementations." Clearly this statement is about delimiting a
class of programs, and not about the quality of implementation of
a compiler or whole implementation. But Keith doesn't get that.

Try compiling Keith's program with gcc -pedantic-errors. I expect
you will find, as I did, that gcc flags the conversion with an error
and doesn't produce an output file. The C standard allows such
behavior only if the source file being compiled is not strictly
conforming. I have more confidence in gcc's understanding of the C
standard than I do in yours.

> On 2023-11-14 at 12:03, Tim Rentsch wrote:
> ...
>> When reading a statement or a question from someone, it's imporant
>> to understand what the writer thinks about what the statement or
>> question means. Similarly, when writing a statement or a question
>> for another person or persons, it's important to express what one
>> hopes to communicate in a way that will be understood by the
>> expected or intended audience as having the same meaning as what
>> the writer hopes to convey.
>>
>> Does this last paragraph make sense? Would you say you agree with
>> it?
>
> Yes, it does. And I frequently despair of ever figuring out a way
> to say what I mean that will be understood as intended by you. [...]

The problem is not me understanding you, but you not understanding
me. Your mental model for how to use and understand natural
language is peculiar. Also rigid and inflexible. Probably the most
troublesome property is that you are focused on argument more than
on understanding. You read the words but don't understand the
meaning. Instead you insist on playing idiosyncratic word games,
apparently believing that how you interpret the words is universal
and absolute. It isn't. Assigning meaning to natural language is
inherently a subjective process, not an objective one. You're a lot
better at arguing than you are at listening. You might want to
think about that.

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

> 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?

The code is not strictly conforming.

> Do you see a syntax rule or constraint that it violates?

No.

> Do you see some other basis for rejecting it?"

Yes. The conversion expression can be untranslatable on some
platforms. That means any such expression cannot be part of
a strictly conforming program.

> 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.

It is the pointer conversion expression that makes the program be
not strictly conforming.

> 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,

I'm not.

> 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.

I have no interest in treating you as a student. I'd be much
happier if you would do more thinking for yourself.

On 2023-11-19 at 02:28 EST, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
>
>> Most fundamentally, what I an hoping to accomplish is to convince
>> you to answer Keith's question.
>
> Consider a C compiler for a machine where function pointers are
> much bigger than any object pointer type. Functions might even
> live in a completely different address space than data (a
> so-called Harvard architecture). On such a machine there is no
> sensible way to change an object pointer into a function pointer,
> or vice versa. Naturally the compiler would prefer to choose not
> to translate any source file that contains such a conversion.

But the standard does not allow such behavior - if they wish to claim
conformance to the C standard, they'll have to do something other than
what they'd prefer. Since the code with undefined behavior is protected
by an if(0), an implementation is not required to generate the
impossible conversion code, and is required to accept the program.

> The C standard doesn't say function pointers may be converted to
> object pointers, or the other way around. The obvious thing to
> do is simply give an error message and forego the translation
> effort. It doesn't make sense that the standard would insist
> that an implementation translate a construct that is nonsensical,
> not just in a particular case but in every possible case.

I appreciate that you feel that way - but the committee resolved DR 109
in conflict with your feeling. The code referred to by DR 109 divided an
integer by an integer constant of 0, which wasn't even protected by an
if(0). It was the only line in the only function defined in that
translation unit, which was absolutely guaranteed, if function were
called, to execute that line. The only reason the committee gave for it
being strictly conforming was that there was no guarantee that the rest
of the program ever actually called the function. But the committee
decided that that fact was sufficient to make the code, in itself,
strictly conforming, and the implementation was therefore required to
accept it. If the program as a whole did call that function, that fact
would be sufficient to justify rejecting the whole program, but it was
not sufficient to justify rejecting that particular translation unit.

Basically, code with undefined behavior prevents a program from being
strictly conforming only if execution of such code is an inevitable
consequence of starting the program. If executing that code can be
avoided, then only a failure to avoid it renders the the behavior
undefined. If that failure is not realized at compile time, then the
implementation must still accept it.

If the committee ruled that way on that code, how could you possibly
expect it to support rejection of this code?

> Converting between function pointers and object pointers isn't
> like dividing by zero.

True - there's implementations which can meaningfully do such a
conversion - there's no meaningful way to divide an integer by 0 (a
floating point calculation could reasonably produce infinity, if
infinity can be represented on that hardware). Which makes the
committee's decision on DR 109 even stronger.

> An impediment to giving Keith an answer to his question is that
> what he's looking for is not just a response but an argument.
> That is, it's important that what I say not only be something he
> understands but also something that convinces him.

That seems reasonable. When you disagreed with Keith's assertion that
the code has no syntax errors or constraint violations, we were
interested partly because of the possibility that you were correct - if
so, there's either a rule we're unaware of or one that we didn't realize
was applicable. Of course, I would never write code like that - putting
code inside an if(0) block is almost never a reasonable thing to do,
except as an ad-hoc version control method. However, if there is such a
rule, I might end up breaking it in some other, more reasonable context,
so I want to know about it.
However, if you're unable to provide a convincing argument that your
point of view is correct, then it's a point of view that is, quite
frankly, of no interest.

....
> for example, or the idea that "accept" does or should mean a
> program must be successfully translated and executed, are clearly
> at odds with the plain language says about what programs must be
> accepted.

There's nothing at all clear about it. The standard leaves "accept"
undefined. It would be odd for the standard to use both "accept" and
"successfully translate and execute", if those two phrases had exactly
the same meaning. However, the "one program" clause is already
sufficiently odd that I'm not willing to that reason to say that they
must have different meanings.

....
> Try compiling Keith's program with gcc -pedantic-errors. I expect
> you will find, as I did, that gcc flags the conversion with an error
> and doesn't produce an output file. The C standard allows such
> behavior only if the source file being compiled is not strictly
> conforming. I have more confidence in gcc's understanding of the C
> standard than I do in yours.

I have considerable trust in gcc, but more trust in the actual words of
the standard. Where there's a disagreement, I favor the actual words of
the standard. And, having seen how you interpret the standard, I
certainly trust my interpretation more than yours.

....
>> Yes, it does. And I frequently despair of ever figuring out a way
>> to say what I mean that will be understood as intended by you. [...]
>
> The problem is not me understanding you, but you not understanding
> me. Your mental model for how to use and understand natural
> language is peculiar. Also rigid and inflexible. Probably the most
> troublesome property is that you are focused on argument more than
> on understanding. You read the words but don't understand the
> meaning. Instead you insist on playing idiosyncratic word games,
> apparently believing that how you interpret the words is universal
> and absolute. It isn't. Assigning meaning to natural language is
> inherently a subjective process, not an objective one. You're a lot
> better at arguing than you are at listening. You might want to
> think about that.

Subjectivity is fine for poetry - but we're talking about a standard. To
the extent that the meaning of words is subjective, they are unsuitable
for use in a standard. The whole point of the standard is to standardize
the requirements - that is, to make them exactly the same for everyone.
If you have to use subjective interpretations to determine what the
requirements are, the standard has failed the purpose for which it was
intended. An implementor could use it's subjective opinion to justify
implementing C in a way that would be inconsistent with the subjective
opinion of a user.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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?
>
> The code is not strictly conforming.
>
>> Do you see a syntax rule or constraint that it violates?
>
> No.
>
>> Do you see some other basis for rejecting it?"
>
> Yes. The conversion expression can be untranslatable on some
> platforms. That means any such expression cannot be part of
> a strictly conforming program.

I disagree. A conforming implementation could implement a conversion of
an object pointer to a function pointer that always yields a null
pointer, or that yields a pointer whose representation is derived from
the representation of the operand. The latter is typically done for
pointer-to-integer or integer-to-pointer conversions with mismatched
sizes (6.3.2.3 explicitly says that integers may be converted to
pointers and vice versa).

If, hypothetically, the standard said that an otherwise valid program
containing a conversion of an object pointer to a function pointer type
must be successfully translated, then compiler implementers could easily
find a way to implement such conversions, even if the result is not
useful. It is incorrect to claim that such a conversion expression may
be "untranslatable".

[...]

> I have no interest in treating you as a student. I'd be much
> happier if you would do more thinking for yourself.

I would be happier if you would not assume that I'm not already
doing that. Be less arrogant.

--
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 */

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> I appreciate that you feel that way - but the committee resolved DR 109
> in conflict with your feeling. The code referred to by DR 109 divided an
> integer by an integer constant of 0, which wasn't even protected by an
> if(0). It was the only line in the only function defined in that
> translation unit, which was absolutely guaranteed, if function were
> called, to execute that line. The only reason the committee gave for it
> being strictly conforming was that there was no guarantee that the rest
> of the program ever actually called the function. But the committee
> decided that that fact was sufficient to make the code, in itself,
> strictly conforming, and the implementation was therefore required to
> accept it. If the program as a whole did call that function, that fact
> would be sufficient to justify rejecting the whole program, but it was
> not sufficient to justify rejecting that particular translation unit.
>
> Basically, code with undefined behavior prevents a program from being
> strictly conforming only if execution of such code is an inevitable
> consequence of starting the program. If executing that code can be
> avoided, then only a failure to avoid it renders the the behavior
> undefined. If that failure is not realized at compile time, then the
> implementation must still accept it.
>
> If the committee ruled that way on that code, how could you possibly
> expect it to support rejection of this code?
[...]

For context, DR 109 can be seen at:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_109.html

The code the author (Ron Guilmette) asked about was (indentation added):

int array1[5];
int array2[5];
int *p1 = &array1[0];
int *p2 = &array2[0];

int foo()
{ int i;
i = (p1 > p2); /* Must this be "successfully translated"? */
1/0; /* Must this be "successfully translated"? */
return 0;
}

The committee response was:

The C Standard uses the term ``indeterminately valued'' not
``undefined value.'' Use of an indeterminate valued object
results in undefined behavior. The footnote to subclause 5.1.1.3
points out that an implementation is free to produce any number
of diagnostics as long as a valid program is still correctly
translated. If an expression whose evaulation would result
in undefined behavior appears in a context where a constant
expression is required, the containing program is not strictly
conforming. Furthermore, 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.

The DR was submitted in 1993, and referred to the C90 standard.
I'm not aware of anything in later editions of the standard that
would invalidate the response.

--
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.T...@gmail.com> writes:
>
>> 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?
>
> The code is not strictly conforming.
>
>> Do you see a syntax rule or constraint that it violates?
>
> No.
>
>> Do you see some other basis for rejecting it?"
>
> Yes. The conversion expression can be untranslatable on some
> platforms. That means any such expression cannot be part of
> a strictly conforming program.

The committee has officially ruled in DR 109 that code with undefined
behavior renders the program not strictly conforming, only if execution
of that code is an inevitable consequence of running the program. Not
only is execution of this code not inevitable, it is in fact impossible
for it to be executed.

I'm curious - on what platform is it impossible, or at least difficult,
to translate an if(0) block as a no-op? I'd think that simply failing to
generate any corresponding machine code would be sufficient on most, if
not all, platforms.

The code that appeared in DR 109 was not a no-op, but the behavior of
any program that called the function would be undefined, which means
that the standard imposes no requirements on its behavior. On what
platform is it difficult to generate code that has no requirements on
how it behaves? I'd think it would be trivial translate it as, for
instance, the equivalent of

fprintf(stderr, "ISO C does not define the behavior of converting \n"
"a pointer to an object into a pointer to a function.\n");
exit(EXIT_FAILURE);

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Phil Carmody <pc+usenet@asdf.org> writes:
>> There's wording in the standard to support the "object" claim, but
>> I'm not seeing direct support for the "type" claim. Of course, there
>> might be a chain of deductions that leads there.
>
> Here is my reasoning.
>
> The sizeof operator works on both expressions (including expressions
> that designate objects) and type names.
>
> The result of sizeof has type size_t.
>
> In <stdint.h>, the preprocessor symbol SIZE_MAX gives the maximum
> value (for that implementation) of a value of type size_t. SIZE_MAX
> has a lower bound of 65535 (a minimum implementation limit). So any
> type whose size exceeds this value is violating the restriction that
> strictly conforming programs not exceed a minimum implementation
> limit. (Sorry if that was belaboring the obvious.)

Yup, that has no holes, AFAICS.

>>>> clang retains its stance on the concept:
>>>>
>>>> """
>>>> phil@dovespaz:~$ clang -Wall -o crap crap.c
>>>> crap.c:11:59: error: array is too large (2305843009213693952 elements)
>>>> printf( " large has %21zu bytes\n", sizeof(char[2305843009213693952]));
>>>> ^~~~~~~~~~~~~~~~~~~
>>>> 1 error generated.
>>>> """
>>>>
>>>> Is there an "array", /per se/? I only see a type.
>>>
>>> An array type, but no array object. I think most people would say
>>> there isn't an array, but just a type.
>>
>> The standard uses the word "array" as a noun to refer to an array
>> object, so I was using the same usage as the standard there.
>
> Looking through the standard, I see that the word array is used both
> as an adjective and as a noun.

I only looked through about a third of 1570, but I only saw noun uses.
I saw noun+noun compound nouns, with the first noun being "array", but
that doesn't make the word an adjective.

An actual adjectival use could be:
*The object is array.
(as per "The bus is red.") the likes of which I couldn't find.

Yes, this is more a.u.e. than c.l.c.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 11/20/23 18:29, Phil Carmody wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
....
>> Looking through the standard, I see that the word array is used both
>> as an adjective and as a noun.
>
> I only looked through about a third of 1570, but I only saw noun uses.
> I saw noun+noun compound nouns, with the first noun being "array", but
> that doesn't make the word an adjective.

In such usages, "array" is technically referred to as a noun adjunct,
attributive noun, qualifying noun, noun (pre)modifier, or apposite noun
- if there are subtle difference between the meanings of those phrases,
Wikipedia fails to explain them. Like an adjective, such a noun is
defined as modifying the following noun, rather than serving as a noun
in it's own right.

I was completely unaware of any of those terms until I studied what
Wikipedia has to say on the issue just now. For most of my life, that is
precisely what I have described as "a noun serving as an adjective",
because at some point someone taught me to refer to it that way. I
suspect that this is precisely what Tim was referring to. Apparently, a
more correct way to to say what he said would be "Looking through the
standard, I see that the word array is used both to modify other nouns,
and as a noun in its own right."

It doesn't matter what grammar term we use to describe such things.
What's important is that we agree on what the meaning is. A train
station is a station for trains - but it is not in any sense itself a
train. Similarly, an array type is a type that describes an array, but
is not in any sense itself an array. Whether we refer to "array" in the
term "array type" as a noun acting as a verb, or as a noun object is
unimportant.

Phil Carmody <pc+usenet@asdf.org> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Phil Carmody <pc+usenet@asdf.org> writes:
[...]
>>> The standard uses the word "array" as a noun to refer to an array
>>> object, so I was using the same usage as the standard there.
>>
>> Looking through the standard, I see that the word array is used both
>> as an adjective and as a noun.
>
> I only looked through about a third of 1570, but I only saw noun
> uses. I saw noun+noun compound nouns, with the first noun being
> "array", but that doesn't make the word an adjective.

I concede your point of grammar (noting that there is some
specialized terminology related to noun+noun phrases, but
I won't quibble about that).

That said, your earlier statement "The standard uses the word
'array' as a noun to refer to an array object" isn't exactly right
either, as for example the phrase "array type". The word array is
functioning as a modifier, whether we want to call it a noun or an
adjective, and it does not refer to any array object. Furthermore
using an array type (in a way that is well-defined in C) doesn't
necessarily mean that that there is an array object somewhere. I
think that is the key point here.

> An actual adjectival use could be:
> *The object is array.
> (as per "The bus is red.") the likes of which I couldn't find.

Not all adjectives are usable in a "The bus is red" construction.
Many and probabaly even most are, but not all are.

> Yes, this is more a.u.e. than c.l.c.

Noted. I have tried to focus on the C aspects in my response.

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:
>>
>>> 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?
>>
>> The code is not strictly conforming.
>>
>>> Do you see a syntax rule or constraint that it violates?
>>
>> No.
>>
>>> Do you see some other basis for rejecting it?"
>>
>> Yes. The conversion expression can be untranslatable on some
>> platforms. That means any such expression cannot be part of
>> a strictly conforming program.
>
> I disagree. A conforming implementation could implement a
> conversion of an object pointer to a function pointer that always
> yields a null pointer, or that yields a pointer whose representation
> is derived from the representation of the operand. The latter is
> typically done for pointer-to-integer or integer-to-pointer
> conversions with mismatched sizes (6.3.2.3 explicitly says that
> integers may be converted to pointers and vice versa).
>
> If, hypothetically, the standard said that an otherwise valid
> program containing a conversion of an object pointer to a function
> pointer type must be successfully translated, then compiler
> implementers could easily find a way to implement such conversions,
> even if the result is not useful. It is incorrect to claim that
> such a conversion expression may be "untranslatable".

What you mean by translatable is different from what I mean. Of
course it is possible to produce a sequence of bits that conforms
to the bit-level representation of a function pointer. The
problem is that it might not be possible to do that in a way that
is sensible, meaningful, or useful.

The contrast with converting between pointers and integers is
helpful here. Converting a pointer to an integer, even if the
integer type isn't as big as the pointer type, is always
potentially useful, because for example the integer could be used
as a hash function. Integers also have the nice property that
they are dense (not counting padding bits), so producing any old
integer value will never be problematic. (Yes I know about the
rule that if the value cannot be represented the behavior is
undefined, but I'm not talking about that.) Going the other
direction, an integer type whose size is large enough (and almost
always there are such types) can guarantee that converting a
pointer to an integer is invertible. There is a deeper principle
here: the addressing structures used in actual hardware use
integers as the basis for addresses. Converting between integers
and pointers always makes sense at some low level. An exception
to that rule is elaborate function pointers, which can use very
large structured values to represent a pointer to function. This
exception is the primary motivation for the C standard saying
that "The result [of converting a pointer to an integer] need not
be in the range of values of any integer type"; in such cases
the behavior is undefined but it is still always allowed to write
an expression asking for such conversions - it is only trying to
execute these expressions that causes a problem.

Note that the C standard reflects the distinction I'm making
here. The standard specifically specifies that integers may
be converted to pointers, and vice versa. The standard also
specifically specifies that object pointers may be converted to
other object pointers, and that function pointers may be
converted to other function pointers. The standard does NOT
specify that function pointers may be converted to object
pointers, or that object pointers may be converted to function
pointers. This difference corresponds exactly to what I mean
by translatable and untranslatable. This distinction is not
incidental, accidental, or meaningless. On the contrary, it is
certainly deliberate, and goes to the heart of the question here.

>> I have no interest in treating you as a student. I'd be much
>> happier if you would do more thinking for yourself.
>
> I would be happier if you would not assume that I'm not already
> doing that.

It's not assumption but observation. To give an example, not too
long ago you asked a question in comp.std.c asking about undefined
behavior and indeterminate answers. I wrote a long posting in
response, basically going through a thorough and systematic review
of the history in different versions of the C standard. I'm sure
you could have done that yourself if you had tried to do so.

Please note that I'm not saying that you *should* have done that,
only that you *could* have done that.

> Be less arrogant.

I don't think it's arrogant to think or to say that you are
more capable than your comments would otherwise indicate. If
anything it seems just the opposite, that I have a higher
impression of your abilities than might seem to be the case
to a casual reader.

On Fri, 19 Jan 2024 12:49:57 -0800, Tim Rentsch wrote:

> An exception to that rule is elaborate
> function pointers, which can use very large structured values to
> represent a pointer to function.

Real-world example: PowerPC/POWER, where a function reference is two
addresses, one for the code and the other for, I think it’s called the GOT
(“Global Object Table”). Every piece of code assumes its GOT register has
been set up with the right value.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 19 Jan 2024 12:49:57 -0800, Tim Rentsch wrote:
>> An exception to that rule is elaborate
>> function pointers, which can use very large structured values to
>> represent a pointer to function.
>
> Real-world example: PowerPC/POWER, where a function reference is two
> addresses, one for the code and the other for, I think it’s called the GOT
> (“Global Object Table”). Every piece of code assumes its GOT register has
> been set up with the right value.

According to <https://devblogs.microsoft.com/oldnewthing/20180816-00/?p=99505>:

Since each function requires its table of contents to be set
properly, a function pointer on PowerPC is not a pointer to the
first instruction. Instead, it’s a pointer to a structure
consisting of two pointers: The first pointer points to the
first instruction of the function, and the second pointer is
the table of contents for the function.

A quick experiment with a gcc powerpc cross-compiler
(powerpc-linux-gnu-gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0) indicates that
void* and function pointers are the same size, 4 bytes.

I suppose compilers *could* have used that two-pointer structure as the
representation of a function pointer. Possibly that would have broken
code that makes invalid assumptions about function pointer sizes.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Fri, 19 Jan 2024 12:49:57 -0800, Tim Rentsch wrote:
>
>> An exception to that rule is elaborate
>> function pointers, which can use very large structured values to
>> represent a pointer to function.
>
>Real-world example: PowerPC/POWER, where a function reference is two
>addresses, one for the code and the other for, I think it’s called the GOT
>(“Global Object Table”). Every piece of code assumes its GOT register has
>been set up with the right value.

That's called dynamic linking and is only used for inter-library function
calls. Intralibrary and intraapplication function calls don't need the
GOT (Global Offset Table), which is used by all modern Unix and Linux
distributions to support dynamic linking.

On Mon, 22 Jan 2024 16:36:46 GMT, Scott Lurndal wrote:

> .. GOT (Global Offset Table) ...

There had to be actual addresses in there somewhere though, did there not?
Otherwise you would have to ask “offsets to what?”.

I am responding here to two different messages from James Kuyper,
combined for convenience in a single posting. Each segment
starts with an attribution line naming James and giving his email
address, as would appear in a normal followup, and then gives
a Message-ID for that posting.

Incidentally, both of these message seems to be a response to a
posting (or postings) of mine, but they seem not to be linked
in the usual way that newgroup postings. I'm not sure how or
why that happened, but I thought I should mention it.

[..first message..]

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[Message-ID: <uje6vv$gei$1@dont-email.me>]

[This message is missing an attribution line that might have
been something like the following line]

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>>
>>> 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?
>>
>> The code is not strictly conforming.
>>
>>> Do you see a syntax rule or constraint that it violates?
>>
>> No.
>>
>>> Do you see some other basis for rejecting it?"
>>
>> Yes. The conversion expression can be untranslatable on some
>> platforms. That means any such expression cannot be part of
>> a strictly conforming program.
>
> The committee has officially ruled in DR 109 that code with undefined
> behavior renders the program not strictly conforming, only if execution
> of that code is an inevitable consequence of running the program. Not
> only is execution of this code not inevitable, it is in fact impossible
> for it to be executed.

The remarks in DR 109 are irrelevant to what I'm saying. The
program given above fails to be strictly conforming for reasons
that have nothing to do with undefined behavior.

> I'm curious - on what platform is it impossible, or at least
> difficult, to translate an if(0) block as a no-op? I'd think that
> simply failing to generate any corresponding machine code would be
> sufficient on most, if not all, platforms.

I hope you realize that this question is quite irrelevant to the
matter being addressed here.

> The code that appeared in DR 109 was not a no-op, but the behavior
> of any program that called the function would be undefined, which
> means that the standard imposes no requirements on its behavior.
> On what platform is it difficult to generate code that has no
> requirements on how it behaves? I'd think it would be trivial
> translate it as, for instance, the equivalent of
>
> fprintf(stderr, "ISO C does not define the behavior of converting \n"
> "a pointer to an object into a pointer to a function.\n");
> exit(EXIT_FAILURE);

You seem to think that the problem has to do with how to compile
program text that has undefined behavior. It doesn't. Please
see also my response to Keith Thompson's message regarding what
I mean by "translatable".

[..second message..]

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[in a posting with Message-ID: <ujdgc9$3t0ni$1@dont-email.me>]

> On 2023-11-19 at 02:28 EST, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> Most fundamentally, what I an hoping to accomplish is to convince
>>> you to answer Keith's question.
>>
>> Consider a C compiler for a machine where function pointers are
>> much bigger than any object pointer type. Functions might even
>> live in a completely different address space than data (a
>> so-called Harvard architecture). On such a machine there is no
>> sensible way to change an object pointer into a function pointer,
>> or vice versa. Naturally the compiler would prefer to choose not
>> to translate any source file that contains such a conversion.
>
> But the standard does not allow such behavior -

Yes, it does. There's a flaw in your logic in trying to decide
whether the program is strictly conforming.

> if they wish to
> claim conformance to the C standard, they'll have to do something
> other than what they'd prefer. Since the code with undefined
> behavior is protected by an if(0), an implementation is not
> required to generate the impossible conversion code, and is
> required to accept the program.

Let me say again that the question of undefined behavior is
not relevant here. The given program fails to be strictly
conforming for reasons that have nothing to do with undefined
behavior.

>> The C standard doesn't say function pointers may be converted to
>> object pointers, or the other way around. The obvious thing to
>> do is simply give an error message and forego the translation
>> effort. It doesn't make sense that the standard would insist
>> that an implementation translate a construct that is nonsensical,
>> not just in a particular case but in every possible case.
>
> I appreciate that you feel that way - but the committee resolved
> DR 109 in conflict with your feeling.

That is your misunderstanding. The remarks in DR 109 have no
bearing on my conclusions.

> The code referred to by DR
> 109 divided an integer by an integer constant of 0, which wasn't
> even protected by an if(0). It was the only line in the only
> function defined in that translation unit, which was absolutely
> guaranteed, if function were called, to execute that line. The
> only reason the committee gave for it being strictly conforming
> was that there was no guarantee that the rest of the program ever
> actually called the function. But the committee decided that that
> fact was sufficient to make the code, in itself, strictly
> conforming, and the implementation was therefore required to
> accept it. If the program as a whole did call that function, that
> fact would be sufficient to justify rejecting the whole program,
> but it was not sufficient to justify rejecting that particular
> translation unit.

Your phrasing here is slightly off. What was actually said is
that

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.

The undefined behavior not being evaluated doesn't guarantee the
program is strictly conforming. If a program /is/ otherwise
strictly conforming then undefined behavior that is potentially
unevaluated doesn't interfere with that. Do you see the
difference? The problem here is that the code in Keith's program
is not strictly conforming, regardless of whether there is
evaluated undefined behavior.

> Basically, code with undefined behavior prevents a program from
> being strictly conforming only if execution of such code is an
> inevitable consequence of starting the program. If executing that
> code can be avoided, then only a failure to avoid it renders the
> the behavior undefined. If that failure is not realized at
> compile time, then the implementation must still accept it.

If undefined behavior is unavoidable, then the program is not
strictly conforming, and it need not be accepted.

However, if all undefined behavior is potentially not evalauted,
that does not by itself guarantee that the program is strictly
conforming. Furthermore you yourself quoted, in another posting,
the relevant sentence from the C standard that bears on the
question of strict conformance.

> If the committee ruled that way on that code, how could you
> possibly expect it to support rejection of this code?

You think the only things that matter in the two programs are
analogous. They aren't.

>> Converting between function pointers and object pointers isn't
>> like dividing by zero.
>
> True - there's implementations which can meaningfully do such a
> conversion - there's no meaningful way to divide an integer by 0
> (a floating point calculation could reasonably produce infinity,
> if infinity can be represented on that hardware). Which makes the
> committee's decision on DR 109 even stronger.