kicad-developers team mailing list archive
Mailing list archive
Re: Text file open modes
On 9/15/2010 4:14 PM, Dick Hollenbeck wrote:
> 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.
If the files are not too large, wxTextFile handles the \r\n problem in
platform agnostic manner ( at least according to the documentation ). A
better solution might be to use wxTextInputStream. It claims to
represent newlines with a single new line character no matter how line
ending are implemented in the file. It appears the wxWidgets folks have
already had to deal with this problem. I haven't tried it so I cannot
comment on how well this works.
> 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp