www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/12/21/12:31:27

Date: Tue, 21 Dec 1999 13:15:41 +0100
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id: <199912211215.NAA25876@acp3bf.physik.rwth-aachen.de>
To: news AT jgreen4 DOT fsnet DOT co DOT uk (Jason Green)
Cc: djgpp AT delorie DOT com
Subject: Re: parse error
Newsgroups: comp.os.msdos.djgpp
Organization: RWTH Aachen, III. physikalisches Institut B
X-Newsreader: TIN [version 1.2 PL2]
Reply-To: djgpp AT delorie DOT com

In article <hflu5sk8344g0ost23f8k3j5fvg1garqn9 AT 4ax DOT com> you wrote:

> GCC does not recognise CR-only as a line end.  This can be the cause
> of some obscure errors:

> #include <iostream> // rest of source file won't be read!

CR-only is a rare thing to come across. It's what you get in Apple
Macintosh text files. But Mac users usually know they have to transfer
text files as text, not binary, to other architectures, so this
happens rather rarely, anyway. The fact that Macs store a 'file type'
with each file, in their 'resource fork' probably helps to avoid this
type of bug.

OTOH, you'll most probably see right away that something's wrong with
such files, in any DOS or Windows editor, as soon as you open it. I
wouldn't expect any of them to interpret such line endings without
complaining loudly, so it's hard to believe any user could fail to
notice this as the source of problems.

> Another thing to watch out for is make, the *nix version only accepts
> NL line ends and will give some cryptic error messages if it
> encounters a CR.

But that doesn't have any relevance to DJGPP make. It will take either
Unix or DOS style line endings, without any noticeable difference.

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019