Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #139418 > unrolled thread
| Started by | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| First post | 2019-01-04 16:04 +0000 |
| Last post | 2019-01-06 00:46 +0000 |
| Articles | 9 on this page of 69 — 13 participants |
Back to article view | Back to comp.lang.c
calling argumentless function with argument jt@toerring.de (Jens Thoms Toerring) - 2019-01-04 16:04 +0000
Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-04 17:34 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-04 17:30 +0000
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-04 09:50 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 05:58 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 07:56 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 10:56 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 14:55 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 01:29 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 02:20 +0000
Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-06 02:51 +0000
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:12 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 11:53 +0000
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:58 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 11:45 +0000
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:58 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 12:24 +0000
Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 04:34 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:41 +0100
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 04:10 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:51 +0100
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:56 +0100
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 05:20 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:08 +0100
Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 15:59 -0800
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 13:42 +0000
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 06:22 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:19 +0100
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 07:42 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:05 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:30 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 17:44 +0100
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:54 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 08:02 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 08:07 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:16 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:40 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:57 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-09 02:23 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:17 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 16:56 +0000
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 09:12 -0800
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 12:39 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 18:26 +0100
Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 18:52 +0000
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 02:32 -0800
Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 04:38 -0800
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:42 +0100
Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-06 10:27 -0600
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 17:47 +0100
Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-04 19:30 +0100
Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-04 10:55 -0800
Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-05 00:16 -0600
Re: calling argumentless function with argument queequeg@trust.no1 (Queequeg) - 2019-01-07 10:43 +0000
Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-07 16:25 -0600
Re: calling argumentless function with argument Barry Schwarz <schwarzb@dqel.com> - 2019-01-04 09:54 -0800
Re: calling argumentless function with argument Thiago Adams <thiago.adams@gmail.com> - 2019-01-04 10:26 -0800
Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-04 12:07 -0800
Re: calling argumentless function with argument James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-04 15:03 -0500
Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 00:04 +0000
Re: calling argumentless function with argument James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-05 22:36 -0500
Re: calling argumentless function with argument jt@toerring.de (Jens Thoms Toerring) - 2019-01-05 13:17 +0000
Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 06:06 -0800
Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-05 15:42 +0100
Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 14:58 +0000
Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-05 16:11 +0100
Re: calling argumentless function with argument Richard Damon <Richard@Damon-Family.org> - 2019-01-05 11:23 -0500
Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 16:53 +0000
Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-06 00:46 +0000
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-05 22:36 -0500 |
| Message-ID | <q0rt3s$3gq$1@dont-email.me> |
| In reply to | #139431 |
On 1/4/19 19:04, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 1/4/19 11:04, Jens Thoms Toerring wrote:
>>> Hi,
>>>
>>> is there anything to worry about if one calls a function
>>> that takes no arguments with an argument like this?
>>>
>>> void foo(void); // defined somewhere else
>>>
>>> int main(void)
>>> {
>>> void (*p)() = foo;
>>> p(4);
>>> }
>>>
>>> Admittedly a bit of a hack, but could be useful in some
>>> circumstances...
>>> Best ergards, Jens
>>
>> You've already been given the correct answer, but not the relevant citation:
>>
>> "If the expression that denotes the called function has a type that
>> includes a prototype, the number of arguments shall agree with the
>> number of parameters." (6.5.2.2p2).
>
> I think this is the wrong citation. The called function has a type that
> includes a prototype, but the type of the expression that denotes the
> called function does not.
>
> It's paragraph 6, not 2 that applies:
>
> "If the expression that denotes the called function has a type that
> does not include a prototype, the integer promotions are performed on
> each argument, and arguments that have type float are promoted to
> double. These are called the default argument promotions. If the
> number of arguments does not equal the number of parameters, the
> behavior is undefined."
>
> This is not a constraint (it can't be reliably diagnosed so it could
> never be turned into one).
You're right, and I should have noticed that. The fact that a diagnostic
is not required almost certainly played a role in producing the mistaken
belief that this would be a safe thing to do.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2019-01-05 13:17 +0000 |
| Message-ID | <g9bp36F2osvU1@mid.uni-berlin.de> |
| In reply to | #139418 |
Hi,
thank you for the excellent answers! I already had
suspected that there'd be something fishy about this
but couldn't find the relevant sections of the standard.
Concerning the question "what's it possibly good for?":
I'm dealing with an application that has grown over se-
veral years in a somewhat "organical" way;-) It e.g. talks
with energy meters. And when a meter measures a new value
several other subsystems have to be notified. So the module
for the meter contains a number of calls of functions in
those subsystems that may be interested in the fact that a
new measurement is ready (e.g. the accounting subsystem,
the web interface subsystem etc.).
But there are a number of energy meters that have to be
supported, and as they all work quite differently each
has its own module. Now each of these modules contains the
calls to the other subsystems. This involves a lot of code
duplication (not even always done correctly), and then:
why should a module dealing with an enery meter know at
all about all the other subsystems and what they may want
to know?
So we consider moving to a better approach where the meter
just "raises" an event, indicating a new value to be ready,
and the new subsystem for dealing with these events calls a
list of functions that interested subsystems have registered
for this event.
Unfortunately, for historical reasons some of these func-
tions accept a pointer, while others accept no argument.
To minimize the amount of work to implement this and lower
the bar to adopting the new system, it would be helpful if
the existing functions could be used without modifications.
For that being able to call a function that does not accept
arguments with an argument could be quite nice. As it stands
we have to change all these functions to accept an argument
that's ignored anyway, and to hunt down all other calls of
the functions and add a basically useless argument to all
of them.
Of course, this isn't just about energy meters, there
are quite a number of other subsystems where it would be
better if "events" could be raised and then dealt with
by a central instance, distributing the information
to all subsystems that have registered their interest.
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-05 06:06 -0800 |
| Message-ID | <0a2eab23-4453-432b-9183-b63686dde24f@googlegroups.com> |
| In reply to | #139435 |
W dniu sobota, 5 stycznia 2019 14:17:39 UTC+1 użytkownik Jens Thoms Toerring napisał: > Hi, > > thank you for the excellent answers! I already had > suspected that there'd be something fishy about this > but couldn't find the relevant sections of the standard. > > Concerning the question "what's it possibly good for?": > I'm dealing with an application that has grown over se- > veral years in a somewhat "organical" way;-) It e.g. talks > with energy meters. And when a meter measures a new value > several other subsystems have to be notified. So the module > for the meter contains a number of calls of functions in > those subsystems that may be interested in the fact that a > new measurement is ready (e.g. the accounting subsystem, > the web interface subsystem etc.). > > But there are a number of energy meters that have to be > supported, and as they all work quite differently each > has its own module. Now each of these modules contains the > calls to the other subsystems. This involves a lot of code > duplication (not even always done correctly), and then: > why should a module dealing with an enery meter know at > all about all the other subsystems and what they may want > to know? > > So we consider moving to a better approach where the meter > just "raises" an event, indicating a new value to be ready, > and the new subsystem for dealing with these events calls a > list of functions that interested subsystems have registered > for this event. > > Unfortunately, for historical reasons some of these func- > tions accept a pointer, while others accept no argument. > To minimize the amount of work to implement this and lower > the bar to adopting the new system, it would be helpful if > the existing functions could be used without modifications. > For that being able to call a function that does not accept > arguments with an argument could be quite nice. As it stands > we have to change all these functions to accept an argument > that's ignored anyway, and to hunt down all other calls of > the functions and add a basically useless argument to all > of them. > > Of course, this isn't just about energy meters, there > are quite a number of other subsystems where it would be > better if "events" could be raised and then dealt with > by a central instance, distributing the information > to all subsystems that have registered their interest. > hire some fella who just know c programming wery well, will see things clearly and that fella could mend it (not reading into it to much, too specific)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-05 15:42 +0100 |
| Message-ID | <q0qfp7$vnu$1@dont-email.me> |
| In reply to | #139435 |
On 05/01/2019 14:17, Jens Thoms Toerring wrote: > Hi, > > thank you for the excellent answers! I already had > suspected that there'd be something fishy about this > but couldn't find the relevant sections of the standard. > > Concerning the question "what's it possibly good for?": > I'm dealing with an application that has grown over se- > veral years in a somewhat "organical" way;-) It e.g. talks > with energy meters. And when a meter measures a new value > several other subsystems have to be notified. So the module > for the meter contains a number of calls of functions in > those subsystems that may be interested in the fact that a > new measurement is ready (e.g. the accounting subsystem, > the web interface subsystem etc.). > > But there are a number of energy meters that have to be > supported, and as they all work quite differently each > has its own module. Now each of these modules contains the > calls to the other subsystems. This involves a lot of code > duplication (not even always done correctly), and then: > why should a module dealing with an enery meter know at > all about all the other subsystems and what they may want > to know? > > So we consider moving to a better approach where the meter > just "raises" an event, indicating a new value to be ready, > and the new subsystem for dealing with these events calls a > list of functions that interested subsystems have registered > for this event. > > Unfortunately, for historical reasons some of these func- > tions accept a pointer, while others accept no argument. > To minimize the amount of work to implement this and lower > the bar to adopting the new system, it would be helpful if > the existing functions could be used without modifications. > For that being able to call a function that does not accept > arguments with an argument could be quite nice. As it stands > we have to change all these functions to accept an argument > that's ignored anyway, and to hunt down all other calls of > the functions and add a basically useless argument to all > of them. > > Of course, this isn't just about energy meters, there > are quite a number of other subsystems where it would be > better if "events" could be raised and then dealt with > by a central instance, distributing the information > to all subsystems that have registered their interest. > > Best regards, Jens > It sounds like you need to get an abstraction layer in here somewhere so that you can make all these different modules look the same to the higher level. Then your events or callbacks all have the same types and parameters, and it is the abstraction part for each module that translates to the module's individual requirements. With care, such abstractions can have little or no overhead. A common part of this is to use a pointer to a struct for passing data around. That avoids having different sets of parameters for the functions. Behind this struct pointer can be different actual structs, with a common initial sequence, so that different modules can have different details. Basically, it's the C manual equivalent of a C++ class hierarchy.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-05 14:58 +0000 |
| Message-ID | <87ef9rtakz.fsf@bsb.me.uk> |
| In reply to | #139438 |
David Brown <david.brown@hesbynett.no> writes: > On 05/01/2019 14:17, Jens Thoms Toerring wrote: <snip> >> Unfortunately, for historical reasons some of these func- >> tions accept a pointer, while others accept no argument. >> To minimize the amount of work to implement this and lower >> the bar to adopting the new system, it would be helpful if >> the existing functions could be used without modifications. >> For that being able to call a function that does not accept >> arguments with an argument could be quite nice. As it stands >> we have to change all these functions to accept an argument >> that's ignored anyway, and to hunt down all other calls of >> the functions and add a basically useless argument to all >> of them. >> >> Of course, this isn't just about energy meters, there >> are quite a number of other subsystems where it would be >> better if "events" could be raised and then dealt with >> by a central instance, distributing the information >> to all subsystems that have registered their interest. > > It sounds like you need to get an abstraction layer in here somewhere > so that you can make all these different modules look the same to the > higher level. Then your events or callbacks all have the same types > and parameters, and it is the abstraction part for each module that > translates to the module's individual requirements. With care, such > abstractions can have little or no overhead. > > A common part of this is to use a pointer to a struct for passing data > around. That avoids having different sets of parameters for the > functions. Or, quite often, just a void *. This works well when called function knows what sort of thing will be passed to it, and that is very often the case. This avoids having to find some common struct that suits all interfaces both those known now and in those that my be needed in the future. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-05 16:11 +0100 |
| Message-ID | <m2y37zkulv.fsf@despina.home> |
| In reply to | #139435 |
jt@toerring.de (Jens Thoms Toerring) writes:
> Unfortunately, for historical reasons some of these func-
> tions accept a pointer, while others accept no argument.
> To minimize the amount of work to implement this and lower
> the bar to adopting the new system, it would be helpful if
> the existing functions could be used without modifications.
> For that being able to call a function that does not accept
> arguments with an argument could be quite nice. As it stands
> we have to change all these functions to accept an argument
> that's ignored anyway, and to hunt down all other calls of
> the functions and add a basically useless argument to all
> of them.
#include <stdlib.h>
#include <stdio.h>
void foo(void);
void bar(void);
void quux(void*);
void baz(void*);
typedef void (*void_fun)(void);
typedef void (*pointer_fun)(void*);
typedef struct {
enum { f_void, f_pointer } type;
union {
void_fun f_void_fun;
pointer_fun f_pointer_fun;
} fun;
} typed_fun;
void call(typed_fun* fun){
switch(fun->type){
case f_void: fun->fun.f_void_fun(); break;
case f_pointer: fun->fun.f_pointer_fun(NULL); break;}}
typed_fun funs[]={
{ .type=f_void, .fun.f_void_fun=foo },
{ .type=f_void, .fun.f_void_fun=bar },
{ .type=f_pointer, .fun.f_pointer_fun=quux },
{ .type=f_pointer, .fun.f_pointer_fun=baz }};
#define countof(a) (sizeof(a)/(sizeof(a[0])))
int main(){
for(int i=0;i<countof(funs);i++){
call(&funs[i]);}
return 0;}
void foo(void){printf("%s()\n",__FUNCTION__);}
void bar(void){printf("%s()\n",__FUNCTION__);}
void quux(void*arg){printf("%s(%p)\n",__FUNCTION__,arg);}
void baz(void*arg){printf("%s(%p)\n",__FUNCTION__,arg);}
/*
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sat Jan 5 16:10:03
SRC="/tmp/f.c" ; EXE="f" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} && ./${EXE} && echo status = $?
foo()
bar()
quux(0x0)
baz(0x0)
status = 0
Compilation finished at Sat Jan 5 16:10:03
*/
> Of course, this isn't just about energy meters, there
> are quite a number of other subsystems where it would be
> better if "events" could be raised and then dealt with
> by a central instance, distributing the information
> to all subsystems that have registered their interest.
Also, note that if you need to pass a specific pointer to the function,
you can also add it to the typed_fun structure and use it in call().
--
__Pascal J. Bourguignon__
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-01-05 11:23 -0500 |
| Message-ID | <2S4YD.466180$GZ9.339704@fx45.iad> |
| In reply to | #139435 |
When using pointer to functions, one key thing is that you need to be sure that the function has the same signature as the pointer when you actually make the call through it. The Standard allows you to put the 'wrong' signature function into a pointer (normally requiring a cast) for storage purposes, but at actual call time it needs to be the right type. I would thing that the follow code would be a constraint violation due to the mis-matched types: void fun(void); void (*fp)(); fp = fum; since fp is a pointer to a function with unknown parameters, vs a function with no parameters, but maybe there is a statement that makes the unknown parameter function type act like a 'void *' pointer. One use of mis-matched functions to pointers is to have a table (or collection of some sort) of function pointers, perhaps of varying prototype, and also have something that goes with it that defines which type of function it is, and at the call site, you make one of a number of different calls, converting the pointer to the right type with the right parameters, like a calculator where some operations take the top of stack and operate on it and put the results back, while others take two items off and put the answer. You could have a list of functions and an indicator of 1 or 2 parameters. Now, if you really have some functions taking a pointer to something and some taking no parameters, and at the call site you don't know which at the time of the call, then one simple solution is wrap all the functios that take nothing with a wrapper function that takes that pointer to something, and it just call the no parameter function and ignores the parameter, and set the pointer to function to that function so the call matches the destination.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-05 16:53 +0000 |
| Message-ID | <878szzt5a6.fsf@bsb.me.uk> |
| In reply to | #139442 |
Richard Damon <Richard@Damon-Family.org> writes: > When using pointer to functions, one key thing is that you need to be > sure that the function has the same signature as the pointer when you > actually make the call through it. The Standard allows you to put the > 'wrong' signature function into a pointer (normally requiring a cast) > for storage purposes, but at actual call time it needs to be the right type. > > I would thing that the follow code would be a constraint violation due > to the mis-matched types: > > void fun(void); > > void (*fp)(); > > fp = fum; (typo: you meant fp = fun;) > since fp is a pointer to a function with unknown parameters, vs a > function with no parameters, but maybe there is a statement that makes > the unknown parameter function type act like a 'void *' pointer. Yes, the two pointer types are compatible. This is explained in section 6.7.6.3 paragraph 15. The rule is cumbersome, and needs careful reading. Here is some of it -- the part that applies in this case: "For two function types to be compatible, both shall specify compatible return types. ... If one type has a parameter type list and the other type is specified by a function declarator that is not part of a function definition and that contains an empty identifier list, the parameter list shall not have an ellipsis terminator and the type of each parameter shall be compatible with the type that results from the application of the default argument promotions." Essentially, T (*)() is a "universal" pointer type, compatible with most function pointers that return a type compatible with T. I put universal in scare quotes because the rule give two exceptions: when the assigned function (pointer) is variadic, and when it's prototype includes a type that is not compatible with the default argument promotions. Thus both void fv(int, ...); and void fp(short); would cause fp = fv; and fp = fp; to give rise to a diagnostic about assigning incompatible types. (And, of course, void fx(short, ...); would break both rules.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-06 00:46 +0000 |
| Message-ID | <8736q6txy8.fsf@bsb.me.uk> |
| In reply to | #139443 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>"For two function types to be compatible, both shall specify
>>compatible return types. ... If one type has a parameter type list and
>>the other type is specified by a function declarator that is not part
>>of a function definition and that contains an empty identifier list,
>>the parameter list shall not have an ellipsis terminator and the type
>>of each parameter shall be compatible with the type that results from
>>the application of the default argument promotions."
>
> Literally, this would /not/ apply to the function declarator
> »(*p)()« below, because it is "part of a function definition"!
> (The definition of the function »main«.)
There's some helpful context in the preceding paragraphs where a fuller
phrase "a function declarator that is part of a definition of that
function" is used a couple of times. But maybe you want to file a
defect report?
> One might surmise that they had other intentions, but they
> wrote it as quoted above.
>
> |int main(void)
> |{
> | void (*p)() = foo;
> | p(4);
> |}
>
> Also, I wonder what "the default argument promotions" are to
> be applied to here. This is not said clearly. Here, no calls
> are involved, just types. So there are no arguments involved
> here.
I'm never sure if you are really puzzled or just being fussy. Do you
know what is meant? The wording is somewhat metaphorical since, as you
say there is no argument to promote, but tighter wording would be hard
to write. Any suggestions?
--
Ben.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web