[boost] Re: Bug in smart_ptr.hpp

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-02-29 13:13:56

Part of the trouble is that we are distributing zip files, which
know nothing of line conventions.  If we could get our stuff onto
an FTP server we would have less trouble.  At least all the FTP
client/server combinations I've ever used translate line endings
OK.

From: Beman Dawes <beman_at_[hidden]>
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> GET A NEXTCARD VISA, in 30 seconds!  Get rates 
> as low as 0.0% Intro APR and no hidden fees.
> Apply NOW!
> http://click.egroups.com/1/983/1/_/9351/_/951836433/
> 
> -- Check out your group's private Chat room
> -- http://www.egroups.com/ChatPage?listName=boost&m=1
> 
> 
>