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

#139418 — calling argumentless function with argument

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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [next] | [standalone]

#139420

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.

So generally speaking, it is a bad idea.

> 
> Admittedly a bit of a hack, but could be useful in some
> circumstances...
>                        Best ergards, Jens
> 

In what circumstances would it be useful?

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

#139421

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.

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.

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

#139422

W dniu piątek, 4 stycznia 2019 18:31:02 UTC+1 użytkownik Bart napisał:
> 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.
> 
> 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.

te, thats right as far as i know,
it means it will do nothing evil just like normal foo call except caller pushes and pops 4 on stack additionally

worse would be oposite 

void foo(int x){ }

and cast and call it like foo()
in that case iinw you may overwrite probably caller local variable or part of caller local stack

this is not much interesting btw, it is more if you work in disasembly/rev.engeenering, not much use in normal c coding

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

#139436

W dniu piątek, 4 stycznia 2019 18:51:09 UTC+1 użytkownik fir napisał:
> ye, thats right as far as i know,
> it means it will do nothing evil just like normal foo call except caller pushes and pops 4 on stack additionally
> 
> worse would be oposite 
> 
> void foo(int x){ }
> 
> and cast and call it like foo()
> in that case iinw you may overwrite probably caller local variable or part of caller local stack
> 
> this is not much interesting btw, it is more if you work in disasembly/rev.engeenering, not much use in normal c coding


some side note here would be that from
some theoretical point of view cdecl is better (than stdcall)

this is becouse if you use cdecl you caould factorise call to function and 
passing arguments on two separate steps

push(10,20,"aaa");
call foo

in case of stdcl yu cannot su simply factorize

btw i once was saying thet theoreticlly
it is possible to also get back variadic 
results
in that case you could wrote

push(10,20);
call foo
take(x,y,z,w);

though in that case, you would probabyu better use separate stacks (at least 2,
one seprate for callreturns only and at least one for arguments + local ariables)

though strictly speaking maybe it is not hardly required

you would just then need to store those ret values down-part of the stack and be ready that other function call will erase it


hovever i rather would like to hae more stacks , i think c program should maybe have at least 2 (minimum), 4 or 8

heving more stack you get couple of very cheap resizable local arrays to free use
(and i gues you would want 2 or 3 at hand)

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

#139441

speaking on stacks and other containers

worth noting arrays and stack are only two containers c cupports (though this support of stack is internal, so this is sorta unusual support know what i mean)

as i said many times c can support also resizable array it can be just done,
(now it seems maybe not so shocking
but when i realized this years ago it was really sorta surprising, now its not so at least to me as years passed)

int tab[10];
//.....
 tab.size++;
 tab[tab.size-1] = 10;

//upsize array 1 up and add 10 at last cell

hovever i never yet was saing on extensions to it... i mean i was saing relatively a lot on chunk based containers and even wrote one 2-dimensional to use it to hold text in a
text editor but was not saying on 
built-in version as that above

some experiences taken form that case of editor can be probably said here, in a form of something that can be built-in
(but wait a minute.. i will share some remarks)

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

#139445

W dniu sobota, 5 stycznia 2019 16:56:31 UTC+1 użytkownik fir napisał:
> speaking on stacks and other containers
> 
> worth noting arrays and stack are only two containers c cupports (though this support of stack is internal, so this is sorta unusual support know what i mean)
> 
> as i said many times c can support also resizable array it can be just done,
> (now it seems maybe not so shocking
> but when i realized this years ago it was really sorta surprising, now its not so at least to me as years passed)
> 
> int tab[10];
> //.....
>  tab.size++;
>  tab[tab.size-1] = 10;
> 
> //upsize array 1 up and add 10 at last cell
> 
> hovever i never yet was saing on extensions to it... i mean i was saing relatively a lot on chunk based containers and even wrote one 2-dimensional to use it to hold text in a
> text editor but was not saying on 
> built-in version as that above
> 
> some experiences taken form that case of editor can be probably said here, in a form of something that can be built-in
> (but wait a minute.. i will share some remarks)

sitting to it it showed i get not much interesting things to say (mostly its even what i said before but there may be some slivers of something new here, so here it goes )


one thing is 
if c will have resiziable array if to add
some things like "insert" and "cut"
(resizability sorta opens a way to consider it)

the question is if such operations are not overally ratcher wrong (and in older times, (like aroind 2003 or 2006) i would be probably to closer to guess its maybe rather bad, 

now i would be closer to say it may be acceptable .. there are maybe spare usecases whan thats ok (those editor i wrote seemed to be that usecase)

hovever ther is some doubt to me

hovever i could assume it may be explored,
if so there is a question how it could look like and what it will bring

both insert and cut probably can be realized by some syntax like

tab1[range1] = tab2[range2];

replacing subset of tab1 by some sobset of tab2

details could depent how you define ranges .. i once sai by favourite is 
begin, end inclusive but some coding made
me thought if begin, length is not sometimes or often better, and if i should use firstm second or maybe both..i dont know, 


char[] tab = "my name is firr";

if [3,0] would be subset(pos, lenhth) operator 

tab[3,0] = "nick";
tab[tab.size-1,1] = ""'

should yeild to tab being "my nickname is fir";

not sure if its worth it, (and especialy if this syntax is standable, maybe not quite, maybe ading some shortcut syntaax will go better? i dont know) ...generally im like wanted maybe to say about more of this extensions to 1d resizable arrays but right now got no idea..so this topic is just opened, hovever minimal value is in noticing this is an open question

such array arithemtic as

char[] x = "alice" + " " + "cat";

x+=" ";

x-=" cat ";

seem mostly like okay to me
so maybe such shortcuts like

x-="cat"+="dog" //some syntax to replace substring)

would work better, such small algebra could be invented), (here above dog could be added at end or at the place where cat wac cutted, imo it probably would cut first cat word on left in source so dog could be added in that place hovever option to add dog just at the and of source also would be nneded, it also should probably work that way that if no cat in the source so no dog is inserted so that just needs inventin some complete rules of some string-algebra


as to strings there is maybe also such curiosity whan sat tab[7] is some letter in string &tab[7] can be considered as a place in string, just before this char so thia may be maybe used in such algebra

&tab[7]+="cat" 

add (insert) cat just before 7-index leter, where instead deletes dont work on &tab[7] but rather on tab[7] content

well i dont kno it began to look very specific when i just thinked by ading a dose of extensions for cutting and inserting in resisable arrays

well dont matter now

secont topis, that seem more importan
are just dwo dimansional resizable arrays

if that 
resizable char[200] tab;
or that
resizable char tab[200];
is resizeble array (i may use both forms though firs seem maybe better)

then 

resizable (resizable char[200])[30] tab

//abstracting a bit out syntax as always, i mean syntax could be changed 

would be resizable array of resizable arrays (those values 200 , 30 are only initial sizes, if you replace resizable by fixed you could get resizavle array of fixed arrays of fixed-size array of resizable rrays

that imo should simply work

in that case sizes could be chngel like

tab.size +=6; //resize array of arrays

tab[44].size+=10; //resize 44-th array ina array of arrays

array of arrrays will in case of holding resizable arrays will be an array of 2-pouinters to specific resizable arrays, most probably stored on heep

not to say to much on it maybe but
what is important is the fact that this kind of container comes into play
(it is like c analogon of some containers
knowed from other languages)

hearing on those oython or c++ containers i always wondered which ones of those are like 'natura', and yhis c 2d-resizable array is imo answer to that

and thats important - what you got in c now

1 fixed array
2 stack (iimplicite, though i also sayin it can be made more explicite too)
3 resizable 1-d array (with eventuall supporting algebra)
4 resizavle 2-d (and 3d etc) array

(those support algebra hovever showed need more consideration to be done, and not to dwell in some heavy swamp)

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

#139446

W dniu sobota, 5 stycznia 2019 20:17:01 UTC+1 użytkownik fir napisał:
> 
> such array arithemtic as
> 
> char[] x = "alice" + " " + "cat";
> 
> x+=" ";
> 
> x-=" cat ";
> 
> seem mostly like okay to me

some side thoughts
1) soem may imagine that resizable chunks of chars could be one fundamental type uin some language/irtual machine, ifnts floats, images, music everything can be puted intio that so elementary operations on such elementary typec could be imagine as important thing (so defining it well will be defining important thing, that may mean it  is wortj to put some effort in it (in definig such small algebra

2)

as to things like 

> 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

for sure things like

print("ala ("+i+")");

would be more nice to use, but here what printf internally do now its done by underlyin routines fired by operators

normally that would involving some memory coping (proportional to final string so not much big) and seem it would be slower than printf wersion 

still i think its rather good to do this kind of string arithmetic, if someone would like to spare those string assemblation and thus memcopy i think there coyld be provided version of printf that tahkes array of strings and in that case

chars[] t = "ala (", str(i), ")";
print(t);

and in that case there would be 
no copy

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

#139448

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


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

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

#139450

On 06/01/2019 00:29, Pascal J. Bourguignon wrote:
> fir <profesor.fir@gmail.com> writes:

>> 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;}

Version in standard C (yours had problems under Windows):

----------------
#include <stdio.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){
		printf("%.*s",strlen(arg),arg);
		arg = va_arg(strings, const char*);}
	va_end(strings);}

int main(void){
     char* i="Hello";
     print("ala (",i,")","\n",NULL);
     return 0;}

--------------

(And it was run like this:)

   C:\c>bcc -run c
   Compiling c.c to c.exe
   ala (Hello)


-- 
bart

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

#139451

Bart <bc@freeuk.com> writes:

> On 06/01/2019 00:29, Pascal J. Bourguignon wrote:
>> fir <profesor.fir@gmail.com> writes:
>
>>> 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;}
>
> Version in standard C (yours had problems under Windows):
>
> ----------------
> #include <stdio.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){
> 		printf("%.*s",strlen(arg),arg);

This needs a cast (not "needs" in your sense of the word, just in C's
sense) because strlen returns size_t.  But what's it for anyway?  Why
not just

  fputs(arg, stdout);

?

> 		arg = va_arg(strings, const char*);}
> 	va_end(strings);}
>
> int main(void){
>     char* i="Hello";
>     print("ala (",i,")","\n",NULL);
>     return 0;}

Mind you, both replies seem to be missing the point since the context
makes it clear that in fir's post i is not a char * (nor a char[]).

-- 
Ben.

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

#139454

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>> int main(void){
>>     char* i="Hello";
>>     print("ala (",i,")","\n",NULL);
>>     return 0;}
>
> Mind you, both replies seem to be missing the point since the context
> makes it clear that in fir's post i is not a char * (nor a char[]).

The point is that if you want to handle arguments of different types,
you need to tell the function what type of argument you're passing. This
is why we have printf:  printf("%s%d%s%s","ala (",i,")","\n");

Otherwise int i=1; "foo"+i is already given a meaning in C.  And a quite
different meaning than in Java.

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

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

#139456

On 06/01/2019 11:12, Pascal J. Bourguignon wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
>>> int main(void){
>>>      char* i="Hello";
>>>      print("ala (",i,")","\n",NULL);
>>>      return 0;}
>>
>> Mind you, both replies seem to be missing the point since the context
>> makes it clear that in fir's post i is not a char * (nor a char[]).
> 
> The point is that if you want to handle arguments of different types,
> you need to tell the function what type of argument you're passing. This
> is why we have printf:  printf("%s%d%s%s","ala (",i,")","\n");

These were some scatty proposals for new language features. Then you 
would expect this stuff to be taken care of behind the scenes. Plenty of 
languages allow exactly this kind of output list.


> Otherwise int i=1; "foo"+i is already given a meaning in C.  And a quite
> different meaning than in Java.

I don't think compatibility with any existing language (certainly not C) 
was a consideration.

-- 
bart

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

#139458

Bart <bc@freeuk.com> writes:

> On 06/01/2019 11:12, Pascal J. Bourguignon wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>>> int main(void){
>>>>      char* i="Hello";
>>>>      print("ala (",i,")","\n",NULL);
>>>>      return 0;}
>>>
>>> Mind you, both replies seem to be missing the point since the context
>>> makes it clear that in fir's post i is not a char * (nor a char[]).
>>
>> The point is that if you want to handle arguments of different types,
>> you need to tell the function what type of argument you're passing. This
>> is why we have printf:  printf("%s%d%s%s","ala (",i,")","\n");
>
> These were some scatty proposals for new language features. Then you
> would expect this stuff to be taken care of behind the scenes. Plenty
> of languages allow exactly this kind of output list.
>
>
>> Otherwise int i=1; "foo"+i is already given a meaning in C.  And a quite
>> different meaning than in Java.
>
> I don't think compatibility with any existing language (certainly not
> C) was a consideration.

Sorry, I thought this was comp.lang.c


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

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

#139455

On 06/01/2019 02:51, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> 		printf("%.*s",strlen(arg),arg);
>
> This needs a cast (not "needs" in your sense of the word, just in C's
> sense) because strlen returns size_t.

OK.

> But what's it for anyway?  Why
> not just
> 
>    fputs(arg, stdout);
> 
> ?

I wasn't completely sure 'arg' was zero-terminated, otherwise why would 
the original need the length? But I see now it has to be otherwise 
strlen wouldn't work. (It was rather late and I just wanted to run it on 
Windows.)



>> 		arg = va_arg(strings, const char*);}
>> 	va_end(strings);}
>>
>> int main(void){
>>      char* i="Hello";
>>      print("ala (",i,")","\n",NULL);
>>      return 0;}
> 
> Mind you, both replies seem to be missing the point since the context
> makes it clear that in fir's post i is not a char * (nor a char[]).

The original examples weren't very good as they were either too simple, 
or underspecified so that they could be expressed as C code.

-- 
bart

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

#139457

Bart <bc@freeuk.com> writes:

> On 06/01/2019 02:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> 		printf("%.*s",strlen(arg),arg);
>>
>> This needs a cast (not "needs" in your sense of the word, just in C's
>> sense) because strlen returns size_t.
>
> OK.
>
>> But what's it for anyway?  Why
>> not just
>>
>>    fputs(arg, stdout);
>>
>> ?
>
> I wasn't completely sure 'arg' was zero-terminated, otherwise why
> would the original need the length? But I see now it has to be
> otherwise strlen wouldn't work. (It was rather late and I just wanted
> to run it on Windows.)


That's just your vanilla C programmers. They're traumatised by buffer
overflow so they keep trying to pass explicit lengths everywhere, and of
course, they introduce more problems doing so than relying on
zero-terminated strings.

They're basically incapable of introducing and using any abstraction.


    printf("%.*s",strlen(arg),arg);

is one of the dumbest forms you can find.  It should be written:

    printf("%s",arg);



>>> 		arg = va_arg(strings, const char*);}
>>> 	va_end(strings);}
>>>
>>> int main(void){
>>>      char* i="Hello";
>>>      print("ala (",i,")","\n",NULL);
>>>      return 0;}
>>
>> Mind you, both replies seem to be missing the point since the context
>> makes it clear that in fir's post i is not a char * (nor a char[]).
>
> The original examples weren't very good as they were either too
> simple, or underspecified so that they could be expressed as C code.

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

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

#139460

On 06/01/2019 11:58, Pascal J. Bourguignon wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 06/01/2019 02:51, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> 		printf("%.*s",strlen(arg),arg);
>>>
>>> This needs a cast (not "needs" in your sense of the word, just in C's
>>> sense) because strlen returns size_t.
>>
>> OK.
>>
>>> But what's it for anyway?  Why
>>> not just
>>>
>>>     fputs(arg, stdout);
>>>
>>> ?
>>
>> I wasn't completely sure 'arg' was zero-terminated, otherwise why
>> would the original need the length? But I see now it has to be
>> otherwise strlen wouldn't work. (It was rather late and I just wanted
>> to run it on Windows.)
> 
> 
> That's just your vanilla C programmers. They're traumatised by buffer
> overflow so they keep trying to pass explicit lengths everywhere, and of
> course, they introduce more problems doing so than relying on
> zero-terminated strings.
> 
> They're basically incapable of introducing and using any abstraction.
> 
> 
>      printf("%.*s",strlen(arg),arg);
> 
> is one of the dumbest forms you can find.  It should be written:
> 
>      printf("%s",arg);

So why did you use:

       write(0,arg,strlen(arg));

in your code; what's the strlen(arg) for?

Anyway I use the "%.*s" format frequently, eg. when calling f/printf as 
a foreign function from languages that use counted, non-zero-terminated 
strings.

Normally this is from some terminal function, where the only choice of 
doing any console or file output is to use standard C functions (that 
work on any OS), or to use OS-specific ones.

-- 
bart

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

#139461

Bart <bc@freeuk.com> writes:
> On 06/01/2019 11:58, Pascal J. Bourguignon wrote:
[...]
>>      printf("%.*s",strlen(arg),arg);
>> 
>> is one of the dumbest forms you can find.  It should be written:
>> 
>>      printf("%s",arg);

I'd use fputs(arg, stdout) but there's something to be said for the
simplicity of using printf consistently.

> So why did you use:
>
>        write(0,arg,strlen(arg));
>
> in your code; what's the strlen(arg) for?

write() (which is defined by POSIX, not by C) doesn't work with
null-terminated strings, so the strlen() is necessary.  (I'm not
addressing the decision to use write() rather than a standard C output
function).

[...]

-- 
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]

#139463

Bart <bc@freeuk.com> writes:

>>      printf("%.*s",strlen(arg),arg);
>>
>> is one of the dumbest forms you can find.  It should be written:
>>
>>      printf("%s",arg);
>
> So why did you use:
>
>       write(0,arg,strlen(arg));
>
> in your code; what's the strlen(arg) for?

Because write(2) doesn't take a string as argument, but a buffer that can
contain nul bytes, and a size.


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

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

#139459

W dniu niedziela, 6 stycznia 2019 12:45:13 UTC+1 użytkownik Bart napisał:
> On 06/01/2019 02:51, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> 
> >> 		printf("%.*s",strlen(arg),arg);
> >
> > This needs a cast (not "needs" in your sense of the word, just in C's
> > sense) because strlen returns size_t.
> 
> OK.
> 
> > But what's it for anyway?  Why
> > not just
> > 
> >    fputs(arg, stdout);
> > 
> > ?
> 
> I wasn't completely sure 'arg' was zero-terminated, otherwise why would 
> the original need the length? But I see now it has to be otherwise 
> strlen wouldn't work. (It was rather late and I just wanted to run it on 
> Windows.)
> 
> 
> 
> >> 		arg = va_arg(strings, const char*);}
> >> 	va_end(strings);}
> >>
> >> int main(void){
> >>      char* i="Hello";
> >>      print("ala (",i,")","\n",NULL);
> >>      return 0;}
> > 
> > Mind you, both replies seem to be missing the point since the context
> > makes it clear that in fir's post i is not a char * (nor a char[]).
> 
> The original examples weren't very good as they were either too simple, 
> or underspecified so that they could be expressed as C code.
> 

it was like that

float f = 2.53;
int i = 3;

char txt[] = "ala has "+i+" cats and "+f+" dogs";

print(txt);


would produce text of the content "ala has 3 cats and 2.53 dogs" then print in on screen

the code is fired by operators and fires the underlying ftos and itoa action then then assemblies the resulted 5 chips of text into one resizable array (located most probably on heap or on stack if that code was local to function)

this is considered extension of c (small part of it as i consider rethinking whole algebra of operators not only +) (this algebra i call 'algebra' or 'string algebra')


some problem it dont seems quite c style but i would like to reconsider it anyway

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web