kicad-developers team mailing list archive
Mailing list archive
Re: Text file open modes
On 09/15/2010 02:55 PM, Lorenzo Marcantonio wrote:
> On Wed, 15 Sep 2010, Dick Hollenbeck wrote:
>> "rt" as the fopen() mode. Won't that make the fgets() code read in
>> lines of text without the \r in a platform independent way ?
> In your dreams:D the 't' modifier is windows (and msdos) only. By ANSI
> specs all letters not understood are ignored so (linux) libc accept it,
> i.e. open the file, but opens it in 'binary' mode. OTOH there is a 'b'
> letter in the standard to force binary mode (which is ignored too, since
> it's always in effect). Since macosx is bsd based I think the same
> applies, too.
> In effect the meaning of the 't' is 'native text', not 'windows text' so
> it does make sense that fopen hasn't a switch for CRLF processing
> (otherwise what about, i.e., old macos which was CR only?)
> Also I had some fabricators (and tools!) which had the same problem,
> refusing LF-only lines (they latch on the CR, maybe...). I don't know if
> the gerber specs says something about that (it was a 5-bit baudot paper
> tape standard IIRC) but the problem is there; you can only hope that
> linux and maybe macos users are smart enough to utod or something the
>> No doubt gerbview needs a lot of work, and I'm not even sure what's
>> there is to be considered a good starting point. I've spent some time
>> on it, but have always had the feeling I was building on sand.
> gerbv is *years* ahead of gerbview...
We have reached the same conclusion. linux's fgets() will return the \r
into the buffer no matter how the DOS file is opened.
Its been so long that I tripped on it that I had forgotten about it on
linux, and this long duration was the result of writing proper code to
avoid it, no doubt.
This recent episode was like stubbing your toe in the dark on something
you had forgotten to move out of the middle of the room, but had been
luckily side stepping for years.
The automatic \r removal is an artifact of the windows version of
fgets(), at least it was at one time. Such a thing is not present in
the linux glibc fgets(), so linux programs should plan on seeing \r when
reading DOS text files.