OpenEuphoria

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