RE: Inconsistent hierarchy

RE: Inconsistent hierarchy

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 22 February 2001 03:31
 
 [Rather an old one, but better late than never]

>It turns out that the string '/|\' is valid under PL/I, but
>it escapes the second single-quote under C.  However,
>the compiler seems to have no business whatsoever
>parsing something whose #ifdef condition has not been
>met.  It appears that the respective hierarchies of the
>quote symbol and the #ifdef/#endif pair are reversed
>between these two versions, and according to my own
>perception, it is the PC version whose behavior seems
>more intuitive.

  Well, there would be a slight problem with that: if you stop parsing
the moment you hit a #if 0, how do you know when to start parsing again?
At the very least you'd have to watch out for the #endif; and of course
you've got to watch out for nested #if-#endif pairs, so that you don't
start parsing again too easily, and it gets complex very quickly.

  I believe the C language standard actually specifies that everything
in the source file must be valid C preprocessing tokens, even if it is
enclosed in a #if 0.  It isn't to do with 'hierarchies' (I assume you
mean something like operator precedence here), and if it doesn't happen
on a newer version of the compiler I assume that means that somebody got
annoyed and did something about it.

  I ran across this problem for myself quite a while ago, since I used
to like doing stuff like...

#if 0

    ... code ...

 aha this code isn't finished yet so I shall use if 0 to stop it compiling

#endif

and the preprocessor complained about my unterminated character constant,
having taken the ' in "isn't" for the opening apostrophe of a character
constant.

  This isn't really a solution to your problem, because there isn't one
except to watch out for and correct those apostrophes as you encounter
them; sorry.

      DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Inconsistent hierarchy

[Jerry Miller]

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Friday, February 23, 2001 12:47 PM
Subject: RE: Inconsistent hierarchy


> >-----Original Message-----
> >From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
> >Sent: 22 February 2001 03:31
>
>  [Rather an old one, but better late than never]
>
> >It turns out that the string '/|\' is valid under PL/I, but
> >it escapes the second single-quote under C.  However,
> >the compiler seems to have no business whatsoever
> >parsing something whose #ifdef condition has not been
> >met.  It appears that the respective hierarchies of the
> >quote symbol and the #ifdef/#endif pair are reversed
> >between these two versions, and according to my own
> >perception, it is the PC version whose behavior seems
> >more intuitive.
>
>   Well, there would be a slight problem with that: if you stop parsing
> the moment you hit a #if 0, how do you know when to start parsing again?
> At the very least you'd have to watch out for the #endif; and of course
> you've got to watch out for nested #if-#endif pairs, so that you don't
> start parsing again too easily, and it gets complex very quickly.
-----------------------------
I guess that's true.  Even if a directive must be the first thing on the
line, a string can continue on a new line, particularly if the preceding
line ends with a backslash.

The main reason for my confusion was that two gcc implementations
handle the situation differently.
-----------------------------
>
>   I believe the C language standard actually specifies that everything
> in the source file must be valid C preprocessing tokens, even if it is
> enclosed in a #if 0.  It isn't to do with 'hierarchies' (I assume you
> mean something like operator precedence here), and if it doesn't happen
> on a newer version of the compiler I assume that means that somebody got
> annoyed and did something about it.
------------------------
Yes, "precedence" is the word I was looking for.  Just another of my
"senior moments" when my whaddyacallit goes blank for a while!
------------------------
>
>   I ran across this problem for myself quite a while ago, since I used
> to like doing stuff like...
>
> #if 0
>
>     ... code ...
>
>  aha this code isn't finished yet so I shall use if 0 to stop it compiling
>
> #endif
>
> and the preprocessor complained about my unterminated character constant,
> having taken the ' in "isn't" for the opening apostrophe of a character
> constant.
>
>   This isn't really a solution to your problem, because there isn't one
> except to watch out for and correct those apostrophes as you encounter
> them; sorry.
>
>       DaveK
> --
> we are not seats or eyeballs or end users or consumers.
> we are human beings - and our reach exceeds your grasp.
>                     deal with it.                      - cluetrain.org
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>

RE: Inconsistent hierarchy

[David Korn]

>I guess that's true.  Even if a directive must be the first thing on the
>line, a string can continue on a new line, particularly if the preceding
>line ends with a backslash.

  And in fact, I believe the "directive must begin in column one and there
may not be any whitespace between the # and the command (if, ifdef etc)
itself" rule has never been strictly enforced.

>The main reason for my confusion was that two gcc implementations
>handle the situation differently.

  You only quoted the version number for the solaris system; are you sure
the gcc on your windows box is the same version?

      DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Inconsistent hierarchy

[Jerry Miller]

I'm developing code that will run under both
UNIX (i.e., Solaris) and Windows NT (using
Interix/Posix on top of NT).  In both cases, I
am using gcc for compilation.

The Solaris version is sparc-sun-solaris2.6-gcc;
the version supplied with Interix has the following
directory entry:
05/15/98  11:04p               137,216 gcc

For the purpose of self-documentation, I have left
my original PL/I code intact and written the C code
around it.  Using /**/ to comment out code is not
practical, because comments cannot be nested;
therefore, I have used
#ifdef ABCDEFGHIJKLMNOPQRSTUVWXYZ
#endif
to isolate the PL/I code.  This has worked without
a problem under NT; however, when I strip out
carriage returns and attempt to compile the otherwise
exact same code on the Sun, I get a complaint about
a mismatched quote.

It turns out that the string '/|\' is valid under PL/I, but
it escapes the second single-quote under C.  However,
the compiler seems to have no business whatsoever
parsing something whose #ifdef condition has not been
met.  It appears that the respective hierarchies of the
quote symbol and the #ifdef/#endif pair are reversed
between these two versions, and according to my own
perception, it is the PC version whose behavior seems
more intuitive.