www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/06/21/05:44:11

From: "Hans Walheim" <HANS AT iar DOT se>
Organization: IAR SYSTEMS AB
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Tue, 21 Jun 1994 10:29:48 CET
Subject: Re: O_TEXT/O_BINARY grief

>    From: jes AT mbio DOT med DOT upenn DOT edu (Joe Smith)
> 
>    > The DEC Alpha C compiler objects to every CR in a CR/LF-delimited file.
> 
>    Gee, and I thought whitespace in C programs wasn't significant, ever
>    since K&R.  Shows how confused *I* can get!  ;-)
> 
>    <Joe
> 

I recognise this problem, we get some reports every year from 
customers writing their source on MSDOS and compiling it on UNIX or 
vice versa.

This is (of course!) addressed in the ANSI standard in 2.1.1.2 
'Translation phases'.  Quoting from phase 1:
"...(introducing new-line characters for end-of-line indicators)..."

The problem is if the source is written on one OS and then compiled on 
another OS, then the compiler usually do not recognise the 'end-
of-line indicator' (CR, CR-LF, LF-CR, LF, ...) so the mapping to the 
'new-line character' will not work properly.  (Maybe there is someone 
out there who knows how to solve this problem without using AI :), in 
that case I am more than interested)

And when we are discussing Translation phases (which actually is a 
very beatiful concept for describing such an awkward thing as the 
preprocessor), it is pointed out in phase 3 that new-line characters 
are retained, (since they are important in the 'line-concept' used in 
the preprocessor for macros, preprocessor-directives and C++ comments)
although the new-line character is a white-space character and is of 
no significance in the later phases.

/Hans Walheim

- Raw text -


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