Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #177212
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Call to a function |
| Date | 2023-10-03 06:34 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86jzs3de3h.fsf@linuxsc.com> (permalink) |
| References | <call-20230922130647@ram.dialup.fu-berlin.de> <20230922081706.858@kylheku.com> <87zg1et4wv.fsf@nosuchdomain.example.com> |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > >> On 2023-09-22, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >> >>> When "1" is cast to a function type and then this is called, >>> one would expect this call to have undefined behavior. But >>> I can only find this in the C specification: >>> >>> |If a converted pointer is used to call a function whose type >>> |is not compatible with the referenced type, the behavior is >>> |undefined. >> >> Because ISO C supports conversions between function pointer types, >> above, the document is addressing what happens in the situation >> when the address of a function is converted to a different pointer type, >> which is then called. E.g. int puts(const char *) is misused as >> a void (double) function: >> >> void (*fptr)(double) = (void (*)(double)) puts; >> >> So far, the behavior is defined: the conversion is valid. >> The pointer could be converted to the correct type and used: >> >> So, the above remarks make it clear that >> >> fptr(3.14); >> >> isn't defined. >> >>> . At the address "1" there is not "a function whose type is not >>> compatible", but no function at all. >> >> The conversion is not supported by ISO C, and so itself has >> undefined behavior: >> >> void (*fptr)(double) = (void (*)(double)) 1; > > The original post used "1", a string literal. You assumed it was an > integer constant in quotes. I would say inferred rather than assumed. Clearly the OP was using double quotes as a way of delimiting code, in much the same way that some people use back tick (backward facing single quotes); note that the original text also says "f()" to indicate a function call, and there is no doubt that "f()" is not meant to include the quotes as part of the code. > The point is the same either way, [...] 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.
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