[boost] Re: Bug in smart_ptr.hpp

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-29 09:27:23

At 07:45 AM 2/29/00 -0500, John Maddock wrote:

>>Some of the lines in smart_ptr.hpp ends with ASCII 13 (CR) this
>>triggers a compilation error with gcc-2.95.2 on Redhat 6.1 systems
at
>>least.
><
>
>I had a lot of problems like this when I first started distributing
>regex++, in the end I put together a short program (not very pretty)
to:
>
>strip all \r's
>optionally strip tabs (and expand with spaces)
>ensure that all files end in \n (some Unixes complain if this isn't
the
>case)

This problem has been reported several times.  Tom Plum started a
discussion of the issue on the C++ committee's core reflector.  It
doesn't sound like the committee considers the current wording in the
standard to be defective.  They see it more as a quality of
implementation issue.

Here is description of the problem by Tony Hansen:

>>>>
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.

<<<<

So it really isn't something we can fix by changes in our files by
picking one of the native formats and converting everything to that
format.  That just moves the problem to people who use other native
formats.  We need to get compiler writers to move into the modern
age.  The compiler people keep complaining about is gcc (particularly
in macro definitions).  Could someone familiar with gcc please submit
a bug report to the gcc people?

--Beman