egcs fails after backslash in macro

[Beman Dawes <beman at esva dot net>]

Based on various bug reports regarding the www.boost.org smart pointer
library, which contains a header with a line or two inserted using a Mac
program editor, it looks like recent versions of gcc including
gcc-2.95.2 have a bug:

If a macro line ending with a backslash is terminated by a CR, and the
platform's native line terminator is something other than CR (^M), gcc
fails to recognize the line termination.

There was some discussion of this on the C++ Standard Committee's core
reflector.  Tony Hansen summed it up:

This is the crux of the matter: the definition of "might reasonably be
encountered on the platform" is changing. For decades now, people
writing Unix and Windows software (almost) always wrote it to only
handle the native file format. It was felt that was a reasonable thing
to do and you (almost) never encountered files in any other format.

Times have changed with networking, and you now do commonly encounter
files with line formats other than the native file format. Hence,
people's expectations have changed. A program writer needs to be less
parochial these days if they want to keep their customers happy.

Unfortunately, not all software vendors (including compiler vendors)
have gotten the clue yet. I get just as frustrated when I find a Windows
program that doesn't handle LF-only files, as I do with Unix programs
that don't handle CRLF-only files.

Are there any LFCR systems? (I can't say I've ever heard of one.) If
not, the line ending rules are simple: any one of LF, CRLF or CR (as
scanned left to right) should be treated as an end of line.

--Beman Dawes