Preprocessor Problem?

Preprocessor Problem?

[linguist-gcc]

It seems odd that I did not find this issue in the FAQ, but I did not.  If
it is in there please sed -e 's/flame/where it is/' your reply.

I am attempting to port some c++ code that uses the following construct:

#define whatever(x) \
class _whatever_x { \
  void something() {} \
}

For some reason, it appears that gcc does not accept backslash escaped newlines in macro definitions?!?!?!  I haven't heard of anything in the new standard about this, have I missed something?

Joining all the lines, and removing the backslashes causes the (now even more horrible looking) code to compile, what what's up with that?

Re: Preprocessor Problem?

[Martin v. Loewis]

> I am attempting to port some c++ code that uses the following construct:
> 
> #define whatever(x) \
> class _whatever_x { \
>   void something() {} \
> }

> For some reason, it appears that gcc does not accept backslash
> escaped newlines in macro definitions?!?!?!

Sure it does. There is a chance that a Carriage Return character
follows the backslash, so there is whitespace after the backslash,
before the newline character. Of course, without seeing the original
source code, it is hard to tell.

Regards,
Martin

Re: Preprocessor Problem?

[Zack Weinberg]

On Sat, May 27, 2000 at 11:23:33PM +0200, Martin v. Loewis wrote:
> > I am attempting to port some c++ code that uses the following construct:
> > 
> > #define whatever(x) \
> > class _whatever_x { \
> >   void something() {} \
> > }
> 
> > For some reason, it appears that gcc does not accept backslash
> > escaped newlines in macro definitions?!?!?!
> 
> Sure it does. There is a chance that a Carriage Return character
> follows the backslash, so there is whitespace after the backslash,
> before the newline character.

... in which case a development snapshot will work as expected.

zw

Re: Preprocessor Problem?

[linguist-gcc]

On Sat, 27 May 2000, Zack Weinberg wrote:

> On Sat, May 27, 2000 at 11:23:33PM +0200, Martin v. Loewis wrote:
> > > I am attempting to port some c++ code that uses the following construct:
> > > 
> > > #define whatever(x) \
> > > class _whatever_x { \
> > >   void something() {} \
> > > }
> > 
> > > For some reason, it appears that gcc does not accept backslash
> > > escaped newlines in macro definitions?!?!?!
> > 
> > Sure it does. There is a chance that a Carriage Return character
> > follows the backslash, so there is whitespace after the backslash,
> > before the newline character.
> 
> ... in which case a development snapshot will work as expected.
> 
> zw
> 

Thank you both ... these files were indeed dragged from a dos machine, with
their damn line endings intact.

I'm also pleased to know that the new version ignores this ... I've always
thought that the best way to handle CR's in a text file was to ignore them
intirely ... this would tend to be the 'right thing' in most cases ... like
shell scripts and programs, and eliminate one source of DOS annoyance.

Re: Preprocessor Problem?

[Zack Weinberg]

On Sat, May 27, 2000 at 07:55:24PM -0400, linguist-gcc@rich-paul.net wrote:
> 
> 
> On Sat, 27 May 2000, Zack Weinberg wrote:
> 
> > On Sat, May 27, 2000 at 11:23:33PM +0200, Martin v. Loewis wrote:
> > > > I am attempting to port some c++ code that uses the following construct:
> > > > 
> > > > #define whatever(x) \
> > > > class _whatever_x { \
> > > >   void something() {} \
> > > > }
> > > 
> > > > For some reason, it appears that gcc does not accept backslash
> > > > escaped newlines in macro definitions?!?!?!
> > > 
> > > Sure it does. There is a chance that a Carriage Return character
> > > follows the backslash, so there is whitespace after the backslash,
> > > before the newline character.
> > 
> > ... in which case a development snapshot will work as expected.
> 
> Thank you both ... these files were indeed dragged from a dos machine, with
> their damn line endings intact.
> 
> I'm also pleased to know that the new version ignores this ... I've always
> thought that the best way to handle CR's in a text file was to ignore them
> intirely

It is slightly trickier than that.  \n, \r, \r\n, and \n\r are all
used as line terminators on platforms currently in use.  We have to
take care to handle them all equally.

zw

Re: Preprocessor Problem?

[Neil Booth]

linguist-gcc@rich-paul.net wrote:-

> Thank you both ... these files were indeed dragged from a dos machine, with
> their damn line endings intact.
> 
> I'm also pleased to know that the new version ignores this ... I've always
> thought that the best way to handle CR's in a text file was to ignore them
> intirely ... this would tend to be the 'right thing' in most cases ... like
> shell scripts and programs, and eliminate one source of DOS annoyance.

Even better, soon (not quite in the snapshots yet) the preprocessor
will warn if it encounters a backslash separated by whitespace from
any of the 4 newline possibilities.

Neil.

Re: Preprocessor Problem?

[Per Bothner]

Neil Booth <NeilB@earthling.net> writes:

> Even better, soon (not quite in the snapshots yet) the preprocessor
> will warn if it encounters a backslash separated by whitespace from
> any of the 4 newline possibilities.

Or perhaps we should just silently ignore spaces between a backslash
and end-of-line.  That is non-traditional, but it is the only sensible
behavior, and I'm quite sure it is compatible with relevant C
standards.  In fact, it is the only clean behavior for "text files" as
opposed to "binary files".  A "text file" does not have semantic
meaning that depends on end-of-line conventions or other non-visible
characters.  Making the number of spaces at the end of a line be
signifigant means you can't represent your programs on punch cards, or
other fixed-line-length file formats, or (more importantly these days)
on printed output.  (I.e. you can't print out a C program and scan it
back in again.)

Inside a quoted string, we need to warn about any non-standard line
terminators (including cr-nl or backslash-space-nl), since the correct
behavior may be surprising and what ends up in the actual string may
not be what the programmer expects; elsewhere, there is no real need to
warn about backslash-space-nl, except to warn about something many
compilers get wrong.

(I'm satisfied that the compiler will now warn about backslash-space-nl
- but in such a case, it is more correct to ignore the space than to
ignore the backslash!)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/