Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #379498 > unrolled thread

Re: Call to a function

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-10 12:08 -0500
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 08:16 -0800
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-13 14:15 -0500
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-14 09:02 -0800
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-14 13:10 -0500
        Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-18 23:27 -0800
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 12:22 -0500
        Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:31 -0800
        Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 18:15 -0800

#379498 — Re: Call to a function

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

[toc] | [next] | [standalone]

#379504

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.

I don't see what it is you are hoping to accomplish with the
above comments.  Can you shed some light on that?

[toc] | [prev] | [next] | [standalone]

#379505

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?

[toc] | [prev] | [next] | [standalone]

#379509

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?

[toc] | [prev] | [next] | [standalone]

#379510

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.

[toc] | [prev] | [next] | [standalone]

#379516

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.

[toc] | [prev] | [next] | [standalone]

#379521

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.

[toc] | [prev] | [next] | [standalone]

#379526

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

[toc] | [prev] | [next] | [standalone]

#380666

I have just posted a response to this posting in combination
with some remarks on another posting.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web