Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #177212

Re: Call to a function

Show key headers only | View raw

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

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