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

Groups > comp.lang.c > #163270

Re: on confusing procedure names with the address of procedures

Show all headers | View raw

On 10/30/2021 7:26 AM, James Kuyper wrote:
> On 10/29/21 11:32 PM, Manfred wrote:
> ...
>> In expressions where the function name is used (but not as a call to
>> that function, so not main()), the function is automatically converted
>> to a pointer to function (similar to arrays that decay to pointers in
>> many circumstances).
> 
> The rule you're referring to is "A function designator is an expression
> that has function type. Except when it is the operand of the sizeof
> operator, 69) or the unary & operator, a function designator with type
> "function returning type" is converted to an expression that has type
> "pointer to function returning type"." (6.3.2.1p4).
> The "69)" refers to footnote 69, which points out that "Because this
> conversion does not occur, the operand of the sizeof operator remains a
> function designator and violates the constraints in 6.5.3.4."
> 
> Note that the only exceptions to that rule are for sizeof and &; there
> is no exception to that rule for actual function calls. That's good,
> because the standard imposes a constraint: "The expression that denotes
> the called function 102) shall have type pointer to function returning
> void or returning a complete object type other than an array type."
> (6.5.5.2p1). If it weren't for that automatic conversion, a call to main
> would require the following syntax: "(&main)()".
> 
> Note that this is a change that occurred in C90. K&R C had no such
> conversion, and specified that "A function call is a primary expression
> followed by parentheses ... The primary expression must be of type
> "function returning ...""
> The conversion and the constraint were both introduced when C was first
> standardized, so that main() remained a valid function call, albeit for
> different reasons, both in K&R C and in C90.
> 
> The purpose of the change was to simplify the use of function pointers.
> Before the change, they had to be called using (*function_pointer)().
> That remains a valid expression, since *function_pointer is an
> expression of function type, which automatically gets converted back to
> a pointer, but they can now also be called more directly by using
> function_pointer().
> 

Thanks for the detailed reference to the standard.

> ...
>>     void (*foo)() = bar;
>>
>>     // You can execute the call in both of the following ways:
>>
>>     foo(); // the pointer is implicitly dereferenced
> 
> That hasn't been true since C90.
> 

I guess you mean that the pointer is not "dereferenced", but still the 
expression is a valid call to the function, so the statement "You can 
execute the call in both ways" still holds.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

on confusing procedure names with the address of procedures Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 21:37 -0300
  Re: on confusing procedure names with the address of procedures Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-29 18:29 -0700
  Re: on confusing procedure names with the address of procedures Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 18:33 -0700
  Re: on confusing procedure names with the address of procedures Manfred <noname@add.invalid> - 2021-10-30 05:32 +0200
    Re: on confusing procedure names with the address of procedures James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 01:26 -0400
      Re: on confusing procedure names with the address of procedures Manfred <noname@add.invalid> - 2021-10-30 19:05 +0200
        Re: on confusing procedure names with the address of procedures James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-30 15:17 -0400
  Re: on confusing procedure names with the address of procedures Bart <bc@freeuk.com> - 2021-10-30 11:36 +0100
  Re: on confusing procedure names with the address of procedures Noob <root@127.0.0.1> - 2021-11-01 13:03 +0100

csiph-web