Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: James Kuyper Newsgroups: comp.lang.c Subject: Re: Call to a function Date: Tue, 23 Jan 2024 14:19:09 -0500 Organization: A noiseless patient Spider Lines: 213 Message-ID: References: <20230922081706.858@kylheku.com> <87zg1et4wv.fsf@nosuchdomain.example.com> <86jzs3de3h.fsf@linuxsc.com> <87h6n7tkv4.fsf@nosuchdomain.example.com> <86ttqf2w6p.fsf@linuxsc.com> <86msw11tpp.fsf@linuxsc.com> <87leblhzud.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Date: Tue, 23 Jan 2024 19:19:09 -0000 (UTC) Injection-Info: dont-email.me; posting-host="39c41b92fd2798faeea761dd61d5ee98"; logging-data="1483096"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xFmds82A3N0ie6PJ2AAYNXKhiZjfcxZ8=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:4flfuw+ms9s0fKNdzUuW1Skgojo= In-Reply-To: Content-Language: en-US Bytes: 11295 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 writes: > [Message-ID: ] > > [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 ========== REMAINDER OF ARTICLE TRUNCATED ==========