Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Abstract Syntax Tree for C programs Date: Thu, 13 Jun 2019 13:16:00 -0700 Organization: None to speak of Lines: 62 Message-ID: References: <87ftop38c1.fsf@bsb.me.uk> <98193656-76f0-4718-9a97-a24ba0aa9b7c@googlegroups.com> <4ff90bb7-33e5-4dcd-828f-b0d40f237420@googlegroups.com> <8a72685f-2774-4187-98bf-c9ecd44b3240@googlegroups.com> <6ed2dfc1-a737-4fb3-b59a-3aa1c337061d@googlegroups.com> <86o9398slw.fsf@mailhub.linuxsc.com> <867e9p96m0.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="ad32838390df8d3c60f97453d78060ed"; logging-data="21026"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cH9W2L/N0lReT/DNWZimg" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:2C/5KIVEC/Q1tnbIWKsMtSrWleg= sha1:hRbG0RK8beHt2T85Ji3McbAVgC0= Xref: csiph.com comp.lang.c:144819 David Brown writes: [...] > Your statement here is also consistent with my point. I don't think the > standard was clear enough here - when I read that bit of the standard, I > don't see anything to suggest that converting between function pointers > and object pointers should always be invalid, even with explicit casts. > Equally, I don't see anything suggesting that it should be valid or > defined behaviour. That also means there is nothing to contradict the > Rationale, but nothing to support it either. What exactly does "invalid" mean? The standard is not as clear as it could be, but I don't see any ambiguity in the normative wording. The only lack of clarity is that it omits any definition of the behavior of a casts between function pointers and object pointers, and that kind of omission is explicitly permitted. The Rationale talks about conversions being "invalid", but the word "invalid" is not defined. That's a flaw in the Rationale, not in the Standard. I might guess that "invalid" means "has undefined behavior", but I don't think that's consistent with the way the words "valid" and "invalid" are used in the Standard and especially in the Rationale. (The Standard is more careful to use defined terms.) So what does the standard say about, for example, a cast from a function pointer type to void*? Does it violate a syntax rule? No, and I don't think anyone would disagree on that point. Does it violate a constraint? No; unless I've missed something, nobody has cited a constraint that it violates. Is the behavior defined? No, because the standard doesn't define the behavior. 6.5.4 discusses cast operators, and imposes several constraints on them. None of those constraints restrict casting a function pointer expression to void*. 6.3.2.3 discusses pointer conversions. It discusses the behavior of several kinds of conversions. It says, for example, that "A pointer to an object type may be converted to a pointer to a different object type." It does not say that a pointer to a function type may be converted to a pointer to an object type -- but it doesn't need to say that it's permitted, since 6.5.4 already does. It doesn't define the behavior of such a cast, which means that the behavior is undefined. See 4p2: "... or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined"." The only evidence I've seen that such a cast requires a diagnostic is that statement in the Rationale that it's "invalid", but there is no such statement in the Standard itself. If the Committee had intended to make such casts a constraint violation, they could very easily have said so in the Standard. But such a statement would have made most uses of the POSIX dlsym() function constraint violations, and I presume most committee members would have been aware of that issue. FWIW, section 6.3.2.3 is identical between N1570 and N2310 (the latter is a working draft for C2X). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */