Re: GNAT's Text_IO & empty files

[Gautier <gautier.demontmollin@maths.unine.ch>]

> > When you create a text file and close it without writing
> > anything in it, you get an empty line. This is due to an
> > explicit statement in procedure Terminate_Line from Ada.Text_IO.
> >
> > This causes an annoying compatibility problem a in DOS or Windows
> > context, since you get a 1-line, 2-bytes text instead of a 0-line,
> > 0-byte one.
> 
> What I see is a 1-line 0-bytes file (with gnat 3.10p on linux)
> > ls -al toto
> -rw-r--r--   1 malaise  users           1 Jul  6 20:40 toto
> > od -x toto
> 0000000 000a
> 0000001
> 
> On which platform did you make your test on? Dos?

DOS or Windows

> Which bytes do you get? CR LF? or LF ^Z?

CR LF; should be nothing

(...)

> Creating such empty file on Dos (with an old Meridain, I don't have gnat
> on dos)
> generates an empty file, and with a put("T") generates a 1-byte file
> with 54.

That's the correct behaviour. Same with Alsys Ada, Janus Ada, Turbo Pascal.

> My conclusion is that it is a file formatting question (including file
> terminator).

It's mine too.

> - Unix has a "kind" of standard and Gnat on Linux complies to it.

GNAT on DOS and (one says) on NT too. That's the problem.

> - Dos has another standard (CR/LF and CtrlZ) but many tools I tried on
> Dos don't comply to it (even an ada compiler). Perhaps this convention
> is becomming obsolete.

CtrlZ is obsolete and is not issued by GNAT, so no problem.
On DOS & Windows, CR/LF is facultative (but welcome) at the end of the
last line; for an empty file there must be no CR/LF at all since the
presence of it means that there is 1 (empty) line. Any word processor
will show that.

> - If you remove this new_line, check that text_io is still able to read
> such a file and that it can read a file with some text but no line
> terminator as well.

It works.

> - From the LRM "...the package Text_IO, which provides facilities for
> input and output in human-readable form". Readable with what? :-) Some
> editing tools of the same platform? Then there is a need for a
> "standard" for ascii text on the platform.

Applause! 

-- 
Gautier