Hi Everyone,

I've come across a little problem to do with passing pointers to functions,
as parameters. The results are rather unexpected, take a look at the following
program :



 #include <stdio.h>
 #include <string.h>

 void main( void ),
  myfunc( char, char, char, char, char ) ;

 void main()
 {
  char array[12] ;
  char *ptr = array ;

  strcpy( array, "Hello World" ) ;

  fprintf( stdout, "\n%s\n", ptr ) ;

  myfunc( *ptr++, *ptr++, *ptr++, *ptr++, *ptr ) ;
 }

 void myfunc( char p1, char p2, char p3, char p4, char p5 )
 {
  fprintf( stdout, "\n%c %c %c %c %c\n", p1, p2, p3, p4, p5 ) ;
 }


Now, compiling this and running it, you would expect to see the following
output, wouldn't you? :

 Hello World

 H e l l o

To be honest, I do get this output on an HP 9000/855 B.08.00, using HP's ANSI
C compiler. But on three PC systems I get the following :

 Hello World

 l l e H H

The three systems being Turbo C, Borland C++ and Microsoft C++.

And on an Apollo Apollo 3500 (yep one of the old ones), I get :

 Hello World

 l l l l o

As a programmer, I would expect the first lot to be the correct output, but
I can see why the second lot could be (stack based), but the third is beyond me.

Which is correct ? K&R doesn't mention it !


Hmmmm .. ?

 Luv and huggs,

  Richard.

In <1993Jan15.164443.25402@lut.ac.uk> R.M.Chandler@lut.ac.uk writes:

>Hi Everyone,

*****> comp.std.c++ is about *standards* issues not about user questions;
 that's what comp.lang.c++ is for; please use that newsgroup in the
 future.

>I've come across a little problem to do with passing pointers to functions,
>as parameters. The results are rather unexpected, take a look at the following
>program :



> #include <stdio.h>
> #include <string.h>

> void main( void ),
>  myfunc( char, char, char, char, char ) ;

> void main()
> {
>  char array[12] ;
>  char *ptr = array ;

>  strcpy( array, "Hello World" ) ;

>  fprintf( stdout, "\n%s\n", ptr ) ;

>  myfunc( *ptr++, *ptr++, *ptr++, *ptr++, *ptr ) ;

*****> Order of evaluation of function arguments is undefined.  Thou ought
 not to use the same argument if is has side-effects.

> }

> void myfunc( char p1, char p2, char p3, char p4, char p5 )
> {
>  fprintf( stdout, "\n%c %c %c %c %c\n", p1, p2, p3, p4, p5 ) ;
> }


 [ confusion on differing output between machines elided ]
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

In article <1993Jan15.164443.25402@lut.ac.uk> R.M.Chandler@lut.ac.uk (Richard Chandler) writes:

>   myfunc( *ptr++, *ptr++, *ptr++, *ptr++, *ptr ) ;

> Now, compiling this and running it, you would expect to see the following
> output, wouldn't you? :

Well, it's explicitly undefined in C (because in general, an expression
may not modify a given object more than once); why would you expect
it to be different in C++?
--
    --Andrew Koenig
      ark@europa.att.com

In article <24629@alice.att.com> you write:
>
>Well, it's explicitly undefined in C (because in general, an expression
>may not modify a given object more than once); why would you expect
>it to be different in C++?
>--
>    --Andrew Koenig
>      ark@europa.att.com

I would have expected it to be different in ANSI C ! It seems pretty
fundamental. 8-)

What I'm having difficulty with, is understanding why it's undefined, when
it actually affects the programmer's meaning. A few people have written back
privately explaining this is a comma seperator, rather than an operator. As
far as I know, the comma operator works from left to right, seperating items
inbetween brackets. OK so this is a function call, and is different, but
the compiler is changing the meaning of my program.

I appreciate that it doesn't matter what the compiler does to implement a
function call, as long as it's consistent at both ends, and with all the other
libraries that can be linked in. But that isn't involved in this issue. Here
the order of execution of my parameters is being swapped around.

With the greatest respect ...

  Richard Chandler.

PS In reference to the earlier response about me daring to use this news group,
I consider this to be a standards issue, it isn't a user question. I don't
rely on my C compiler to use the correct precedences, let alone much else !

In article <1993Jan18.095427.20883@lut.ac.uk> R.M.Chandler@lut.ac.uk (Richard Chandler) writes:

> What I'm having difficulty with, is understanding why it's undefined, when
> it actually affects the programmer's meaning.

R.M.Chandler@lut.ac.uk writes:


>What I'm having difficulty with, is understanding why it's undefined, when
>it actually affects the programmer's meaning. A few people have written back

The programmer is a senseless amorphous mass incongruently trying to
draw reasonable reactions from a senseless electronical and mechanical
lump of junk. It cannot possibly have a meaning.

>the compiler is changing the meaning of my program.

Of course. That is so that the junk better comprehends the mass. Masses
jibber high level, and junks gobble only machine language. Ask a junk
the meaning of high level. If you are lucky it will only core dump.

>I appreciate that it doesn't matter what the compiler does to implement a
>function call, as long as it's consistent at both ends, and with all the other
>libraries that can be linked in. But that isn't involved in this issue. Here
>the order of execution of my parameters is being swapped around.

Who would not like to be consistent at both ends.
Who would not dream of having his parameters executed?

Ok, OK, I give up, everyone has provided good arguments, and thanks for your
time.

The conclusion I've come up with is to build my own compiler, then I know
what it's doing ! 8-)

Luv and huggs...

 Richard Chandler