open("filename","rt"),for Bernie and others
- Posted by Al Getz <xaxo at AOL.COM> Nov 20, 2000
- 390 views
With the old 0x1A char out of style, we need to update our software to reflect this change. I think i see what Bernie is trying to say. He's both acknowledging the fact that with OLD software opening a file in the "r" mode interprets a 0x1A char as an end of file EOF char, while at the same time exclaiming that since NEW software doesnt need this capability, any new software language made recently such as Euphoria should ignore the OLD standard completely and simply return the 0x1A char the same as it would any other character even if the file was opened in "r" mode. The responsibility of interpreting the hex 1A char would then be placed on the shoulders of the programmer opening the file (where everything else pertaining to the open file is anyway) rather then the language system's designer. Its irrelevent that the lines end in crlf or #10 or xyz as thats a seperate argument. After all, the standard is outdated now, let it die. While it seems like a great idea to ignore the #1A completely, implementing this now though im sure would damage some code already written out there, as the programmer would then have the responsibility of detecting a 0x1A rather then a -1 as the following code illustrates: fn1=open("filename.txt","r") while 1 do bin=getc(fn1) if bin=#1A then exit --done reading text file end if CallPrimaryRoutine(bin) end while In line 4 above the #1A would have been a -1 or the line would have been: if bin<0 then in order to detect the end of file. This means changing the standard now in Euphoria would cause some code already written to malfunction with some older (very old) text files in which the programmer expected to get a -1 in response to a hex 1A char at the end of the file. Is this correct Bernie? So the designer of a NEW language is faced with the decision: should i ignore the old standard completely and implement opening a file in the "r" mode to return the hex 1A char the same as any other, which would not cause any problems because their is not yet any software out there using the language because its not even out there yet, OR should i implement the old standard as is and let the programmer decide when to use "r" vs "rb", perhaps in a simple decision conditional statement? But the designer of an ESTABLISHED language is faced with a totally different decision: 1. Should i update the language base to return the hex 1A char (when previously it returned a -1 in "r" open mode) which would definitely cause some programs already written out there to crash in the rare case that they read in an old text file written with a cerca 1980 (or so) program, OR 2. Should i simply tell programmers using the language to open the file in "rb" mode if they want to interpret the hex 1A char themselves, and also that they must then detect crlf char combos. OR 3. Provide a third open mode, "rt" for reading a text file void of the old #1A chars, while still interpreting crlf char combos. I definitly opt for choice #3 above!! So i hope we see that in Euphoria soon, but you can see that between the other two choices you would have to pick #2 over #1. Hope this sheads some light on the getc() and its relation to old text, new text, binary files, and updating a language to get rid of this old standard once and for all. --Al