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

On 2024-01-22 00:08, Tim Rentsch wrote:
....
> 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.

I currently have Thunderbird configured to delete any usenet messages
from you. This is not intended to punish you, nor does it incur any
obligation on my part to ignore your questions. It's intended solely to
reduce the amount of aggravation I feel as a result of reading your
messages. As a result, if I end up learning about one of your messages
by other means, and decide that I do want to respond, it's inconvenient
to do so. This is both an advantage and a disadvantage - it discourages
me from responding unless strongly motivated, but it also makes it
inconvenient to respond if I am sufficiently motivated.
I've been using Google Groups to post such messages, but when they cut
that off, I've been forced to switched to a couple of other
work-arounds. I'm not sure which one I used in that message, and the
details aren't important, but I'm not surprised if either method messed
up the message links.

> [..first message..]
>
> James Kuyper <james...@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]
> 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.

And once again, typical Tim Rentsch behavior. This would have been a
perfectly obvious and natural opportunity to insert a statement of what
you think the actual reason is, but you refuse to do so.

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

You said that implementing such a conversion would be difficult. I don't
see what's difficult about a conversion that does not in fact need to be
implemented.

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

The relevant code does not need to be translated, and therefore does not
need to be translatable, since it is literally impossible for it to be
executed.

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

Once again, you passed upon on a perfectly obvious and natural
opportunity to insert a statement explaining what actually renders the
program not strictly conforming.

You could have easily, at any time, short-circuited months of circuitous
arguing by identifying the feature of the program that renders it not
strictly conforming. The only suspect I can find for such a feature is
the fact that the code which never gets executed would have undefined
behavior if it were executed. Since you say that's not the problem, I
have no idea what you think the problem actually is.

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

Again, you passed up on a perfectly obvious and natural opportunity to
insert a statement identifying what you think the reason actually is.

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

Not in any way that is applicable. I see no other way in which it fails
to be strictly conforming. I may have missed something, and you might
have noticed it, which is why we've repeatedly asked you to identify it,
but you have repeatedly and steadfastly refused to explain what that
other way is.
Again, you missed a perfectly obvious and natural opportunity to insert
a statement identifying what it is that you think makes the program not
strictly conforming.

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

Because you refuse to identify what thing it is you think matters.
Once again, you missed a perfectly obvious and natural opportunity to
insert a statement identifying what it is that you think matters.

....
> Again you miss the point. The question of undefined behavior
> has no bearing on the conclusion.

Again, you missed a perfectly natural and obvious opportunity to
identify what it is that you think does have a bearing on the conclusion.

....> I have very little interest in trying to offer an argument
> that convinces you. My conclusions are correct, whether
> my comments convince you or not.

Yes, I've noticed your lack of interest in convince me. But do you have
any idea how frustrating it is to shadow box with someone who refuses to
put his arguments out there so we can decide whether or not they make
any sense. There's a perfectly natural conclusion that can be reached
when someone behaves that way, and that is they are afraid to explain
their arguments, because they know that those arguments are not good
enough to survive public exposure. That might not be your actual reason,
but your behavior entitles us to assume that it is - not because that
would be the most reasonable guess, but as a built-in punishment for
your refusal to communicate.

....
> The problem is not the words of the C standard but what you think
> they mean.

And, again, you missed a perfectly obvious and natural opportunity to
explain what it is you think they actually mean.

....
> I calibrate my understanding of what text in the C standard means
> by comparing it with other sources, including especially remarks
> written or spoken by C standard committee members in other contexts.

And again, you missed a perfectly obvious and natural opportunity to
insert a citation of the relevant remarks that informed you interpretation.

....
> I'm sorry you missed the point of what I was saying.

That's because you refuse to explain it. You just criticize what I say
without bothering to explain your criticism. How could I possibly have
any idea what your point is when you won't explain it?
Again, you missed a perfectly obvious and natural opportunity to insert
an explanation of what your point is.

> Just one more item. Here is a quote from the C Rationale document:
>
> Consequences of the treatment of pointer types in the
> Standard include:
>
> * [...]
>
> * Even with an explicit cast, it is invalid to convert
> a function pointer to an object pointer or a pointer
> to void, or vice versa.
>
> Note in particular the word /invalid/. Not undefined, but
> invalid. What do you suppose is the basis for that statement?

Since the standard doesn't use the term "invalid" in any applicable text
that I could find, I would assume that the basis for this statement is
the fact that the behavior of such a conversion is undefined. The terms
"syntax error", "constraint violation", "unspecified behavior",
"implementation-defined behavior", "undefined behavior", and
"locale-specific", among others, all have requirements (or the lack
thereof) attached to them by the C standard. "invalid" does not. The
behavior of such a conversion is undefined "by omission of any explicit
definition of the behavior", and as far as I know that is the only
relevant problem with it. It doesn't violate any applicable syntax rule
or constraint that I'm aware of. And you've repeatedly refused to
identify one.