Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!asuvax!noao!ncar!mephisto!mcnc!rti!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: &&**
Summary: no, no, no...
Message-ID: <0926@sheol.UUCP>
Date: 9 Sep 90 20:54:55 GMT
References: <1990Sep7.021321.18381@watmath.waterloo.edu> <1990Sep7.080855.24070@irisa.fr>
Lines: 51

> From: ridoux@irisa.fr (Olivier Ridoux)
> "what is the rational of the cc and gcc compilers (sun4) that 
> makes them accept the following program.

Presumably, merely because they are buggy compilers.

> Can I expect that every C compiler will have the same rational ?

I certainly hope not.  It seems to me that about the only way that
allowing &(&(...)) makes any sense at all is as part of a larger
picture that supports the operation of essentially all "lvalue"
requiring operators on value arguments.  This larger context would
have to deal with rules for things like when, how, and for how long
"pseudo-objects" would be created so that lvalue-requiring semantics
could be meaningful.  It might improve the language in some ways.

I emphasize: "might".

Now, on the other hand, I ran this program through microsoft C,
feeling confident that it would be flagged as erronious.  To my
surprise and amazement, it ran just as Olivier describes.  No
slips, no drips, (and worst) no errors.

This is apparently a VERY common bug.  It shakes my faith in
the competence of C implementors.  Unless I'm missing something
quite major...???


(the program in question:)

main()
{
char c = 'c' ;
char * pc = &c ;
char ** ppc = &pc ;

char d = 'd' ;
char * pd = &d ;
char ** ppd = &pd ;

  printf( "%c\n", *(*( &(&(*(*(ppc)))) )) );  /* 1 */

  printf( "%c\n", *(*( &(&(*(*(ppd)))) )) );  /* 2 */

  &(&(*(*(ppc)))) = ppd ;
  printf( "%c\n", *(*( &(&(*(*(ppc)))) )) );  /* 3 */

}
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org