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

Groups > comp.lang.c > #139418 > unrolled thread

calling argumentless function with argument

Back to article view | Back to comp.lang.c

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#139479

On 06/01/2019 15:17, Pascal J. Bourguignon wrote:
> Bart <bc@freeuk.com> writes:
> 
>> Which ones? On this page:
> 
> For example the first programming language I learned, LSE (Langage
> Symbolique d'Enseignement).
> 
>>   http://rosettacode.org/wiki/String_concatenation
>>
>> the most common operator, when it is done by an infix operator, seems
>> to be "+", followed by "&". (I couldn't search for "!" because that
>> occurs in "hello world!" in every example.)
>>
>>> It would be a pure extension to C, so it wouldn't
>>> break any existing program.
> 
> & is already a binary operator.  "foo" & "bar" already means something
> in C, (even if in modern C it produces warnings for the implicit cast).

There are a limited number of readily available symbolic operators. Some 
overloading is necessary.

The use of "+" for something vaguely meaning "addition" is acceptable 
IMO, especially with so much existing practice.

It doesn't need to mean mathematical addition (which itself covers 
scalars, vectors and matrices); I would "add" an extension to my house, 
I wouldn't say "concatenate".

And if I do "abc"+"wxyz", of lengths 3 and 4, then I get a result of 
length 7.

In the case of "&", which can be called "and", it doesn't have a meaning 
in arithmetic, so it can lends itself to several kinds of overloads.

"!" itself also has a meaning in mathematical equations (factorial), and 
is commonly used to mean "not". So of course it's the natural choice to 
combine two strings! (In my languages, and I think in some Fortrans, "!" 
introduces a line comment.)

-- 
bart

[toc] | [prev] | [next] | [standalone]

#139481

W dniu niedziela, 6 stycznia 2019 17:54:40 UTC+1 użytkownik Bart napisał:
> On 06/01/2019 15:17, Pascal J. Bourguignon wrote:
> > Bart <bc@freeuk.com> writes:
> > 
> >> Which ones? On this page:
> > 
> > For example the first programming language I learned, LSE (Langage
> > Symbolique d'Enseignement).
> > 
> >>   http://rosettacode.org/wiki/String_concatenation
> >>
> >> the most common operator, when it is done by an infix operator, seems
> >> to be "+", followed by "&". (I couldn't search for "!" because that
> >> occurs in "hello world!" in every example.)
> >>
> >>> It would be a pure extension to C, so it wouldn't
> >>> break any existing program.
> > 
> > & is already a binary operator.  "foo" & "bar" already means something
> > in C, (even if in modern C it produces warnings for the implicit cast).
> 
> There are a limited number of readily available symbolic operators. Some 
> overloading is necessary.
> 
> The use of "+" for something vaguely meaning "addition" is acceptable 
> IMO, especially with so much existing practice.
> 
> It doesn't need to mean mathematical addition (which itself covers 
> scalars, vectors and matrices); I would "add" an extension to my house, 
> I wouldn't say "concatenate".
> 
> And if I do "abc"+"wxyz", of lengths 3 and 4, then I get a result of 
> length 7.
> 
> In the case of "&", which can be called "and", it doesn't have a meaning 
> in arithmetic, so it can lends itself to several kinds of overloads.
> 
> "!" itself also has a meaning in mathematical equations (factorial), and 
> is commonly used to mean "not". So of course it's the natural choice to 
> combine two strings! (In my languages, and I think in some Fortrans, "!" 
> introduces a line comment.)
> 

the + is not a problem, problem is if adding it to langage (when it works like on memcopies) is not just a pandora box

(it is pandora box) (probably)

this is in situation when tab.size+=5
(i mean resizing tabs) is like okay,
but that above is a bit different story)

(it would be less pandora boks if adding strong to string would not yeild to string but to strings

strings s = "ala " + "ma " + "kota ";

(strings is tab od string (in that case
str tab[3] when str itself is clasical (char* or char[] ) 

maybe that should work that way, but the wuestion is still if forbid pandora

[toc] | [prev] | [next] | [standalone]

#139484

W dniu niedziela, 6 stycznia 2019 18:12:49 UTC+1 użytkownik fir napisał:

> forbid pandora


at least the idea of naming that part of api by pandora (like that planet from avatar) is fine

;c

[toc] | [prev] | [next] | [standalone]

#139482

Bart <bc@freeuk.com> writes:

> "!" itself also has a meaning in mathematical equations (factorial),
> and is commonly used to mean "not".

Both being unary operators!

> So of course it's the natural
> choice to combine two strings!

Indeed, since it's free as a binary operator.


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#139483

On 06/01/2019 17:26, Pascal J. Bourguignon wrote:
> Bart <bc@freeuk.com> writes:
> 
>> "!" itself also has a meaning in mathematical equations (factorial),
>> and is commonly used to mean "not".
> 
> Both being unary operators!
> 
>> So of course it's the natural
>> choice to combine two strings!
> 
> Indeed, since it's free as a binary operator.

I try to avoid such distinctions, except where mixed use is already 
well-established (eg. + - &). (Anyway, postfix unary operators can clash 
with same operator used as infix.)

If 'op' is an operator, then I like the flexibility to be able to use it 
as 'a op b' or 'op(a,b)', or op(a,b,c...).

But my point is really that there is no connection between "!" and 
addition or concatenation, and little prior history of such use (other 
than in that LSE language of yours).

if introduced into a language to mean string addition, then there will 
be a lot more people scratching their heads over it than if "+" was used.

[toc] | [prev] | [next] | [standalone]

#139453

W dniu niedziela, 6 stycznia 2019 01:29:54 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> >> char[] x = "alice" + " " + "cat";
> >
> > if that would be in c language such 
> > things would probably replace tofdays printf suntax, and the question is if that would be good
> 
> 
> -*- mode: compilation; default-directory: "/tmp/" -*-
> Compilation started at Sun Jan  6 01:24:50
> 
> SRC="/tmp/w.c" ; EXE="w" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} &&  ./${EXE} && echo status = $? && echo '---------------' && cat ${SRC}
> alice cat
> status = 0
> ---------------
> #include <unistd.h>
> #include <string.h>
> int main(){
>     char x[]="alice" " " "cat" "\n";
>     write(0,x,strlen(x));
>     return 0;}
> 
> Compilation finished at Sun Jan  6 01:24:50
> 
>     
> 
> 
> > for sure things like
> >
> > print("ala ("+i+")");
> 
> -*- mode: compilation; default-directory: "/tmp/" -*-
> Compilation started at Sun Jan  6 01:29:34
> 
> SRC="/tmp/w.c" ; EXE="w" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} &&  ./${EXE} && echo status = $? && echo '---------------' && cat ${SRC}
> ala (Hello)
> status = 0
> ---------------
> #include <unistd.h>
> #include <string.h>
> #include <stdarg.h>
> 
> void print(const char* string, ...){
> 	va_list strings;
> 	va_start(strings, string);
> 	const char* arg = string;
> 	while (arg){
> 		write(0,arg,strlen(arg));
> 		arg = va_arg(strings, const char*);}
> 	va_end(strings);}
> 
> 
> int main(){
>     char* i="Hello";
>     print("ala (",i,")","\n",NULL);
>     return 0;}
> 
> Compilation finished at Sun Jan  6 01:29:34
> 
> 

my post was on something other
(it was on : if c may have resizable array (that are even quite cheap) it prowokes it to have sort of releted
string algebra

hovever i dont go to much closed conclusions sadly

[toc] | [prev] | [next] | [standalone]

#139462

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> #include <unistd.h>
> #include <string.h>
> int main(){
>     char x[]="alice" " " "cat" "\n";
>     write(0,x,strlen(x));
>     return 0;}

Leaving aside the question of why you're using write() rather than
a standard C output function, why are you writing to standard input
(file descriptor 0)?

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139464

Keith Thompson <kst-u@mib.org> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> [...]
>> #include <unistd.h>
>> #include <string.h>
>> int main(){
>>     char x[]="alice" " " "cat" "\n";
>>     write(0,x,strlen(x));
>>     return 0;}
>
> Leaving aside the question of why you're using write() rather than
> a standard C output function, why are you writing to standard input
> (file descriptor 0)?

Because I assume that's where a print() function would write.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#139475

On Sun, 06 Jan 2019 13:42:37 +0100, "Pascal J. Bourguignon"
<pjb@informatimago.com> wrote:

>Keith Thompson <kst-u@mib.org> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> [...]
>>> #include <unistd.h>
>>> #include <string.h>
>>> int main(){
>>>     char x[]="alice" " " "cat" "\n";
>>>     write(0,x,strlen(x));
>>>     return 0;}
>>
>> Leaving aside the question of why you're using write() rather than
>> a standard C output function, why are you writing to standard input
>> (file descriptor 0)?
>
>Because I assume that's where a print() function would write.


One would assume that a print() function would write to standard
output.  In Posix-like systems that's file descriptor 1.  0  is
standard input.

[toc] | [prev] | [next] | [standalone]

#139478

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Sun, 06 Jan 2019 13:42:37 +0100, "Pascal J. Bourguignon"
> <pjb@informatimago.com> wrote:
>
>>Keith Thompson <kst-u@mib.org> writes:
>>
>>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> [...]
>>>> #include <unistd.h>
>>>> #include <string.h>
>>>> int main(){
>>>>     char x[]="alice" " " "cat" "\n";
>>>>     write(0,x,strlen(x));
>>>>     return 0;}
>>>
>>> Leaving aside the question of why you're using write() rather than
>>> a standard C output function, why are you writing to standard input
>>> (file descriptor 0)?
>>
>>Because I assume that's where a print() function would write.
>
>
> One would assume that a print() function would write to standard
> output.  In Posix-like systems that's file descriptor 1.  0  is
> standard input.

Oh, right.  Sorry, I meant 1.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#139425

On 04/01/2019 18:30, Bart wrote:
> On 04/01/2019 16:34, David Brown wrote:
>> On 04/01/2019 17: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);
>>> }
>>
>> It is undefined behaviour.  It is likely to "work" in most cases (the
>> argument would be put onto the stack or into a register, and then
>> ignored by the called function).
>>
>> However, if the compiler is using a "callee cleanup" calling convention
>> rather than "caller cleanup", you'll be in trouble.  "Caller cleanup" is
>> the traditional for C, especially on *nix systems.  But "callee cleanup"
>> is used with a variety of calling conventions on Windows (like MS
>> fastcall, stdcall, etc.).  If your call requires putting anything on the
>> stack instead of just registers, you'll get in trouble.
> 
> If it's C calling C, then I think caller clean-up is always used (from
> what I've seen on Windows anyway), otherwise it would be harder to
> implement variadic functions such as printf.
> 

You might think that (because it would be sensible), but no.  Some
windows compilers give you a variety of calling conventions - specify
the wrong one, and things do not work.  And it is up to the compiler to
pick its defaults (and certainly up to the compiler if the function is
static).  Other platforms usually have fixed ABI's that specify calling
conventions, and compilers all follow those ABI's, but 32-bit Windows
does not.  (64-bit Windows calling conventions are a bit more standardised.)

Variadic functions do have to be caller clean-up, yes, but that does not
mean that other functions cannot use different calling conventions.

> Calling foreign functions from C might be more of a problem.
> 
> (My language/compiler always used callee clean-up within its functions.
> Such a think would not work.)
> 
>>> Admittedly a bit of a hack, but could be useful in some
>>> circumstances...
> 
>>
>> In what circumstances would it be useful?
> 
> You have a function pointer intended to call a range of functions some
> of which have a parameter, and some don't. But you want to use the same,
> consistent function pointer type and the same call code. Then you want
> those functions without a parameter to ignore it.
> 

It would be better to use a consistent type and parameters in such
cases.  Have the functions take a parameter which they then ignore if
they don't need it.  It is common in such situations to have a "void *"
parameter - this can be used as a pointer to a struct for the data to be
sent, allowing different types of information to be passed safely.

[toc] | [prev] | [next] | [standalone]

#139426

Bart <bc@freeuk.com> writes:
> On 04/01/2019 16:34, David Brown wrote:
>> On 04/01/2019 17:04, Jens Thoms Toerring wrote:
>>>     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);
>>> }
>> 
>> It is undefined behaviour.  It is likely to "work" in most cases (the
>> argument would be put onto the stack or into a register, and then
>> ignored by the called function).
>> 
>> However, if the compiler is using a "callee cleanup" calling convention
>> rather than "caller cleanup", you'll be in trouble.  "Caller cleanup" is
>> the traditional for C, especially on *nix systems.  But "callee cleanup"
>> is used with a variety of calling conventions on Windows (like MS
>> fastcall, stdcall, etc.).  If your call requires putting anything on the
>> stack instead of just registers, you'll get in trouble.
>
> If it's C calling C, then I think caller clean-up is always used (from 
> what I've seen on Windows anyway), otherwise it would be harder to 
> implement variadic functions such as printf.
  
It may well be the case that most or all C compilers use caller cleanup,
at least partly for historical reasons.  It makes it possible, for
example, to call printf without a correct declaration in scope.
(Pre-ANSI C didn't have prototypes, so a compiler wouldn't necessarily
even know that printf is variadic.)

But the standard is carefully worded to permit either caller cleanup or
callee cleanup.  Calling a variadic function with no visible prototype
(or with a prototype that doesn't match the definition) has undefined
behavior, which allows a compiler to treat variadic functions specially.

[...]

>> In what circumstances would it be useful?
>
> You have a function pointer intended to call a range of functions some 
> of which have a parameter, and some don't. But you want to use the same, 
> consistent function pointer type and the same call code. Then you want 
> those functions without a parameter to ignore it.

I can imagine that being useful -- but C doesn't support it with
defined behavior.  Just be aware of the risk that some compiler could
break your code.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139434

On Fri, 4 Jan 2019 17:30:43 +0000, Bart <bc@freeuk.com> wrote:

>On 04/01/2019 16:34, David Brown wrote:
>> On 04/01/2019 17: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);
>>> }
>> 
>> It is undefined behaviour.  It is likely to "work" in most cases (the
>> argument would be put onto the stack or into a register, and then
>> ignored by the called function).
>> 
>> However, if the compiler is using a "callee cleanup" calling convention
>> rather than "caller cleanup", you'll be in trouble.  "Caller cleanup" is
>> the traditional for C, especially on *nix systems.  But "callee cleanup"
>> is used with a variety of calling conventions on Windows (like MS
>> fastcall, stdcall, etc.).  If your call requires putting anything on the
>> stack instead of just registers, you'll get in trouble.
>
>If it's C calling C, then I think caller clean-up is always used (from 
>what I've seen on Windows anyway), otherwise it would be harder to 
>implement variadic functions such as printf.


Watcom's standard 32-bit calling convention for non-variadic functions
was callee cleanup.  MS's default for (non-variadic) member functions
(obviously C++) (aka "thiscall") is callee cleanup.  Many programs
using MS compilers were compiled with "fastcall", which is callee
cleanup except in the case of variadic functions.  Windows/Gcc ports
and Borland support a similar, but not identical, callee cleanup
fastcall option.  The normal gcc convention uses a scheme that has
some things cleaned up by the callee and some by the caller (object
return pointers, specifically).

[toc] | [prev] | [next] | [standalone]

#139491

David Brown <david.brown@hesbynett.no> wrote:

> But "callee cleanup" is used with a variety of calling conventions on 
> Windows (like MS fastcall, stdcall, etc.).

How does "callee cleanup" deal with variable argument list?

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [next] | [standalone]

#139516

On Mon, 7 Jan 2019 10:43:38 +0000 (UTC), queequeg@trust.no1 (Queequeg)
wrote:

>David Brown <david.brown@hesbynett.no> wrote:
>
>> But "callee cleanup" is used with a variety of calling conventions on 
>> Windows (like MS fastcall, stdcall, etc.).
>
>How does "callee cleanup" deal with variable argument list?


Usually for variadic functions the calling convention gets changed.
For example, with MS fastcall or thiscall, variadic functions use the
"standard" cdecl (caller cleanup) calling convention instead.

[toc] | [prev] | [next] | [standalone]

#139423

On 4 Jan 2019 16:04:33 GMT, jt@toerring.de (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...

Why not describe the circumstances you are thinking of and someone may
provide a better approach.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#139424

On Friday, January 4, 2019 at 2:04:43 PM UTC-2, 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...


How about pointer to a function with variable args?
Maybe in this case we can have the same hack but with
guarantees.

[toc] | [prev] | [next] | [standalone]

#139429

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, January 4, 2019 at 2:04:43 PM UTC-2, Jens Thoms Toerring wrote:
>>    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...
>
> How about pointer to a function with variable args?
> Maybe in this case we can have the same hack but with
> guarantees.

A variadic function must have at least one fixed parameter.  However,
any excess arguments are ignored (though they're evaluated before the
call).  For example, this:

    printf("%d\n", 42, i++);

is legal.  It will have the side effect of incrementing i, but the value
is quietly ignored.  (It might produce a compile-time warning, since
it's likely to be a logical error.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139428

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).
This is in the Constraints section of 6.5.2.2, so a diagnostic is
mandatory. If you choose to ignore the diagnostic, and if the
implementation chooses to continue translation of the program, and if
you choose to execute the translated program, the resulting behavior is
undefined.

[toc] | [prev] | [next] | [standalone]

#139431

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).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web