Re: [Plib-devel] Re: [Plib-cvs] plib/src/ssg ssgLoadAC.cxx,1.36,1.37

[steve <sjb...@ai...>]

Bram Stolk wrote:
> steve wrote:
> 
>>Bram Stolk wrote:
>>
>>
>>>Update of /cvsroot/plib/plib/src/ssg
>>>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8823
>>>
>>>Modified Files:
>>>    ssgLoadAC.cxx Log Message:
>>>Avoid append flag. Fix by Mathias
>>
>>
>>-  loader_fd = fopen ( filename, "ra" ) ;
>>+  loader_fd = fopen ( filename, "r" ) ;
>>
>>
>>Wooaaahhhhhh.
>>
>>That's not right!
>>
>>The 'a' flag only means 'append' if it's the first character
>>in the mode string.  In the second position, it should be
>>ignored.  On some systems, an 'a' in the second position
>>means "ASCII" (as opposed to 'b' for binary).
>>
>>I'm sceptical about this patch.
> 
> 
> Well... I'll be happy to reverse it, but I tried to find
> information about this "ra" mode.

Well, exactly - not many OS's use it.  What I'm sceptical
about is how (if at all) it fixes anything.  Mainly though,
the commit comment "Avoid append flag" shows a misunderstanding
of what "ra" means.  It DOES NOT MEAN 'Append'.  That would be
"a" by itself.

So if this patch was intended to fix something - then the
person doing the fixing didn't understand what they were
doing - and we should be sceptical about whether this is
indeed the correct patch.

> I can't find it on the
> net, nor on linux ia32, linux ia64, irix, freebsd manpages.

"ra" is something I've seen in very ancient IBM systems where
the underlying computer used EBCIDIC instead of ASCII and this
flag was used to convert ASCII to EBCIDIC behind the scenes.

But nobody runs PLIB on those machines (if indeed any of them
still exist)!

So I guess that the 'a' at the end of the string was a mistaken
attempt to be the opposite of a 'b' at the end - and so this
probably *is* an error - but one that should be 100% benign.

So I'm left wondering why someone thought this fixed a bug -
and I'm guessing that whatever they did wasn't necessarily
correct and that we should look more carefully and inquire
as to what was intended to be fixed.

> Also, I assume ac is an ascii file

Yes, it is.

> and if on those "some
> systems" it is read as binary, surely there is no harm in
> that? What happens if you read a file as binary, when in
> fact it's ascii?

* Under Linux/UNIX/BSD - nothing bad happens.  A file is
   just a file.  There are no 'ASCII files' and 'Binary files'.

* Under Windows - any \r\n pairs come through unchanged
   instead of being turned into simple \n as you'd expect
   when reading ASCII.  However, programs that run portably
   ought to be prepared for the occasional spurious '\r'
   because files written under Windows but read under
   Linux/UNIX would have any \r's that got stuffed into
   the file by Windows come out literally just as they
   would under Windows if you accidentally opened an ASCII
   file as binary.  Hence well-written, portable programs
   shouldn't care whether a file opened for reading is
   accidentally opened as binary incorrectly.  The reverse
   is not the case however - if you open as ASCII when it's
   really a binary file then 'Very Bad Things' happen.

* Under MacOS-9 - I believe that any \r's in the file get
   read as \r instead of being turned into \n's.   That
   *might* be a bad thing - even for well-written portable
   programs because they are expecting '\n' to terminate a
   line and they'll never see a '\n' because the underlying
   file has a '\r' in it and without the ASCII translation
   mode turned on those '\r's come out as written.

* Under MaxOSX - I'm not sure...probably the same as MacOS-9
   and earlier.

Very ikky for portable programming.

Moral of the story:  UNIX had it right.  Abandon all other
OS's immediately!