Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #177360
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Call to a function |
| Date | 2023-10-03 15:13 -0700 |
| Organization | None to speak of |
| Message-ID | <87h6n7tkv4.fsf@nosuchdomain.example.com> (permalink) |
| References | <call-20230922130647@ram.dialup.fu-berlin.de> <20230922081706.858@kylheku.com> <87zg1et4wv.fsf@nosuchdomain.example.com> <86jzs3de3h.fsf@linuxsc.com> |
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?
Do you see a syntax rule or constraint that it violates? Do you see
some other basis for rejecting it?
int main(void) {
int obj = 42;
typedef void func(void);
if (0) {
func *fptr = (func*)&obj;
fptr();
}
}
--
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 */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 15:21 +0000
Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-22 11:39 -0400
Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 16:47 +0000
Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-23 01:26 -0400
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-23 07:38 -0700
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-22 11:54 -0700
Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 06:34 -0700
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-03 15:13 -0700
Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-04 01:52 +0000
Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-03 19:13 -0700
Re: Call to a function "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-03 20:41 -0700
csiph-web