🚀 go-pugleaf

In article <tran0119.810223973@itlabs.umn.edu> 
tran0119@itlabs.umn.edu () writes:
> rick@iway.com (Rick Ross) writes:
> 
> 
> >Mac  - 0x0D (carriage return or '\r')
> >UNIX - 0x0A (linefeed or '\n')
> >DOS  - 0x0D, 0x0A (carriage return/linefeed pair)
> 
>     I thought you just had to do : 
> 	getline(buff, num_chars);
>     and that will take care of the line delimeter.  Besides, if it's ANSI C,
> the compiler should take care of those conversions (in text mode).  Am I
> missing something here?

The standard library has support for/requires:
* the "raw" or binary format
* a _native_ text format: What the _native_ format is depends on the
library author, and is obviously not portable.

It also has an _internal_ text format, which basically uses '\n'
(usually 0x0a) characters to delimit lines.  The library has to convert
between _internal_ and _native_ formats on all I/O calls.

Nothing prevents the _native_ format from being identical (as in the
case of UNIX - in fact, many pre-std libraries did _not_ have a text
format per se), or different (as in DOS and Mac) from the _internal_
format.

The problem here is that the library does _not_ support _any_ text
format, it does only the _native_ format; and thru the binary/raw
backdoor, the _internal_ format.

All this leads to this: you cannot depend on the standard libary to
handle multiple file formats for you.  You have to write wrapper classes
which handle the format.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash