Re: [9fans] plan9's C compiler and // comments

Re: [9fans] plan9's C compiler and // comments

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Looks like just the opposite to me.  /**/ comments are handled specially.
The prepocessor doesn't know anything about // comments.  If you want to
change it, I wouldn't mind.  I think nobody ever thought of or cared to
do it before because we frown so much on programming with the preprocessor.

The // at the end of your endif makes it through only because everything after the
endif is ignored.

[-- Attachment #2: Type: message/rfc822, Size: 2629 bytes --]

From: Enache Adrian <enache@rdslink.ro>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan9's C compiler and // comments
Date: Mon, 15 Sep 2003 05:21:21 +0300
Message-ID: <20030915022121.GC1290@ratsnest.hole>

> On Sun, Sep 14, 2003 a.d., David Presotto wrote:
> > It accepts it just fine.  You're just defining a macro as
> >
> > 	"wow!"	// this won't work
> >
> > and when it gets expanded in the exits you get
> >
> > void main() { exits("wow!"	// this won't work); }

Judging about what I understand of cmd/cc/macbody:237-260,
ex. the /**/ comments are not passed through macros to be dealt with
later, but discarded during the parsing of the '#define' directive.

So the handling of '//' comments is just special in this case.

Regards,
Adi

Re: [9fans] plan9's C compiler and // comments

[mirtchov]

> I think nobody ever thought of or cared to
> do it before because we frown so much on programming with the preprocessor.

I admit as was truly disappointed when I didn't read "people who
program using the preprocessor should be shot" in Boyd's post :)

Re: [9fans] plan9's C compiler and // comments

[David Presotto]

Of course, even our cpp gets it wrong...  If you feel like fixing it,
might as well go whole hog.

Re: [9fans] plan9's C compiler and // comments

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 54 bytes --]

try adding -+ to allow C++ comments.
worked for me.

[-- Attachment #2: Type: message/rfc822, Size: 2016 bytes --]

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan9's C compiler and // comments
Date: Sun, 14 Sep 2003 23:19:35 -0400
Message-ID: <091866070e78bbd2b2d1b8c920fadb9d@plan9.bell-labs.com>

Of course, even our cpp gets it wrong...  If you feel like fixing it,
might as well go whole hog.

Re: [9fans] plan9's C compiler and // comments

[boyd, rounin]

> I admit as was truly disappointed when I didn't read "people who
> program using the preprocessor should be shot" in Boyd's post :)

i was too busy with awk and thought that anyone using // comments
AND the preprocessor was a fool.

Re: [9fans] plan9's C compiler and // comments

[boyd, rounin]

> I admit as was truly disappointed when I didn't read "people who
> program using the preprocessor should be shot" in Boyd's post :)

or as grampaw pettibone woulda said:

    Land a goshen, only a dadburned idiot would fly
    into the break at five hundred knots.

Re: [9fans] plan9's C compiler and // comments

[Bruce Ellis]

I did the special /**/ stuff because some crappy code depends on
them being elided.  I probably should have done // as well but
decided not to for some reason lost in the past.

brucee
----- Original Message -----
From: "David Presotto" <presotto@closedmind.org>
To: <enache@rdslink.ro>; <9fans@cse.psu.edu>
Sent: Monday, September 15, 2003 1:06 PM
Subject: Re: [9fans] plan9's C compiler and // comments


> Looks like just the opposite to me.  /**/ comments are handled specially.
> The prepocessor doesn't know anything about // comments.  If you want to
> change it, I wouldn't mind.  I think nobody ever thought of or cared to
> do it before because we frown so much on programming with the preprocessor.
>
> The // at the end of your endif makes it through only because everything after the
> endif is ignored.

Re: [9fans] plan9's C compiler and // comments

[boyd, rounin]

> I did the special /**/ stuff because some crappy code depends on
> them being elided.  I probably should have done // as well but
> decided not to for some reason lost in the past.

i wrote a cpp once, when i really wasn't up to the job.

the problem is:

    do you remove the comment from the macro text or just
    leave it in?

in the case of /* ... */ it doesn't make a lotta difference 'cos
during the expansion they could dissappear.

if the case of // they had better be removed from the macro
text 'cos when the expansion comes along you are in a
'world of pain'.

reiser's cpp was blinding fast, and almost unreadable so
you had your work cut out to work out the semantics of
the damn thing.

he had worked out this insight that you were just writing
a _slightly_ smarter version of cat;  it didn't tokenise
much and used one i/o buffer to do all the dirty work.

Re: [9fans] plan9's C compiler and // comments

[Enache Adrian]

On Sun, Sep 14, 2003 a.d., David Presotto wrote:
> Looks like just the opposite to me.  /**/ comments are handled specially.
> The prepocessor doesn't know anything about // comments.  If you want to
> change it, I wouldn't mind.  I think nobody ever thought of or cared to
> do it before because we frown so much on programming with the preprocessor.

Never mind. I stumbled on this when trying to get stuff cut-n-pasted
from external headers working.
I actually fixed that issue with sed.

This should be probably changed only if the compiler is ported outside
plan9 (to make it work like MSVC or gcc, in order to avoid gratuitous
incompatibilities -- but then the whole '#if A && defined(B)' madness
should be probably put in too).

Regards,
Adi

Re: [9fans] plan9's C compiler and // comments

[Charles Forsyth]

>>incompatibilities -- but then the whole '#if A && defined(B)' madness
>>should be probably put in too).

no, there's already a useful, separate cpp, from a venerable source,
that isolates all that complexity.

use -p with ?c to get it when you need it.
use -+ as well if you need // comments.
(with it, cpp handles the #define ... // case being discussed.)

Re: [9fans] plan9's C compiler and // comments

[boyd, rounin]

> I think nobody ever thought of or cared to do it before because
> we frown so much on programming with the preprocessor.

is it the plan 9 C compiler paper that states that use of the
preprocessor has been cut down to the core and its overuse
is discouraged and, in fact, unnecessary?

iirc

i have awk regression tests to run, which are running quite nicely
against /bin/awk which should allow me to incorporate some of
bwk's fixes and then i'll run 'em on my native 'port'.

Re: [9fans] plan9's C compiler and // comments

[Geoff Collyer]

cpp gets abused, but we need it (or m4 or something of the sort), if
only for #include, so it's not completely unnecessary.  The bad old
days, when we walked 5 miles uphill to and from school, were not
pretty: when cpp was an optional compiler pass and /usr/include didn't
exist yet, only the kernel bothered to #include headers, and the
number of bugs in V6 Unix programs because somebody had copied a
struct declaration out of a manual page and then the real struct
changed (or they had copied it incorrectly in the first place) was
considerable.

Re: [9fans] plan9's C compiler and // comments

[steve.simon]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

Hi,

ape/cpp also attempts to do single quote (') matching
inside C++ style comments.

Thus

	int fred = 0; 		// fred's number

causes cpp to spew. Its on my list of things to
track down but not at the top...

-Steve

[-- Attachment #2: Type: message/rfc822, Size: 608 bytes --]

From: 9fans@cse.psu.edu
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan9's C compiler and // comments
Date: Mon, 15 Sep 2003 04:19:35 +0100
Message-ID: <1630899296@snellwilcox.com>

Of course, even our cpp gets it wrong...  If you feel like fixing it,
might as well go whole hog.

Re: [9fans] plan9's C compiler and // comments

[C H Forsyth]

it was quicker to add the few lines of code to fix it
rather than discuss it further: so i did.

Re: [9fans] plan9's C compiler and // comments

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

i can only get that effect when i do NOT include the -+
option, but in that case it's not supposed to do C++ comments
so the effect is correct.

[-- Attachment #2: Type: message/rfc822, Size: 3002 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 230 bytes --]

Hi,

ape/cpp also attempts to do single quote (') matching
inside C++ style comments.

Thus

	int fred = 0; 		// fred's number

causes cpp to spew. Its on my list of things to
track down but not at the top...

-Steve

[-- Attachment #2.1.2: Type: message/rfc822, Size: 608 bytes --]

From: 9fans@cse.psu.edu
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan9's C compiler and // comments
Date: Mon, 15 Sep 2003 04:19:35 +0100
Message-ID: <1630899296@snellwilcox.com>

Of course, even our cpp gets it wrong...  If you feel like fixing it,
might as well go whole hog.

[9fans] plan9's C compiler and // comments

[David Presotto]

It accepts it just fine.  You're just defining a macro as

	"wow!"	// this won't work

and when it gets expanded in the exits you get

void main() { exits("wow!"	// this won't work); }

which eats up the '); }' at the end of the function.

Re: [9fans] plan9's C compiler and // comments

[Enache Adrian]

On Sun, Sep 14, 2003 a.d., David Presotto wrote:
> It accepts it just fine.  You're just defining a macro as
>
> 	"wow!"	// this won't work
>
> and when it gets expanded in the exits you get
>
> void main() { exits("wow!"	// this won't work); }
>
> which eats up the '); }' at the end of the function.

Thanks for clarifying this.
Notice however that this is different from other compilers/preprocessors.
(FWIW, I prefer to stick to old '/* ... */' comments).

Regards,
Adi

Re: [9fans] plan9's C compiler and // comments

[boyd, rounin]

> Notice however that this is different from other compilers/preprocessors.
> (FWIW, I prefer to stick to old '/* ... */' comments).

the problem didn't exist till C++ added //

things were not helped by the complexity of the reiser cpp either.

Re: [9fans] plan9's C compiler and // comments

[Charles Forsyth]

>>things were not helped by the complexity of the reiser cpp either.

the remarkable thing is that later work on C ADDED to the preprocessor,
and even more later!
``when you're in a hole ...''

fortunately, it must be said that even in some of the worst code i've seen
the authors kept to the simpler constructions.  the main problems in practice
tend to be the use of it at all (eg, Linux enumerating arbitrarily many platforms in a single file
controlled by #ifdef!), and overly complex #if expressions (which, not being
checked much can easily go wrong).  a little gem recently was ``#if ndef ...''.

Re: [9fans] plan9's C compiler and // comments

[Enache Adrian]

> On Sun, Sep 14, 2003 a.d., David Presotto wrote:
> > It accepts it just fine.  You're just defining a macro as
> >
> > 	"wow!"	// this won't work
> >
> > and when it gets expanded in the exits you get
> >
> > void main() { exits("wow!"	// this won't work); }

Judging about what I understand of cmd/cc/macbody:237-260,
ex. the /**/ comments are not passed through macros to be dealt with
later, but discarded during the parsing of the '#define' directive.

So the handling of '//' comments is just special in this case.

Regards,
Adi

[9fans] plan9's C compiler and // comments

[Enache Adrian]

The C compiler accepts '//..' C++ -like comments, but not in '#define'
directives.

-----------------------
#include <u.h>
#include <libc.h>

// this one OK
#ifndef FOO
#define EXITS	"wow!"	// this won't work
#endif // this one OK too

void main() { exits(EXITS); }
-----------------------

Is this deliberate behaviour ?

(sorry if it's already fixed, my plan9 is a bit out of date).

Thanks,
Adi