surprise data from Ada.Sequential_IO

surprise data from Ada.Sequential_IO

[John Perry]

Hello all

I was using gnat 2020 CE on a Linux machine the other day, and wanted to write out data for three different types T1, T2, T3 to a file. I instantiated a Sequential_IO package for each; call them P1, P2, P3.

The following worked as expected (sorry for the abbreviations but I think it will be clear):

>> P1.Create; P1.Write; P1.Close; P2.Open(Append_File); P2.Write; P2.Close;

However, this:

>> P3.Open(Append_File); P3.Write; P3.Close;

...wrote a few bytes of junk between T2's data and T3's data.

I used a hex editor to check the output file between writes, and there was no junk after P2.Close nor after P3.Open; it always came at the beginning of P3.Write.

I reworked the type definitions so that T3's data was included at the end of T2, and in this case P2.Write wrote the data properly, as desired. However, this is not the sort of permanent solution I'd want.

Has anyone else encountered this? Could this be due to alignment issues? Is there some way to avoid this without putting the data there?

thanks in advance
john perry

Re: surprise data from Ada.Sequential_IO

[Jeffrey R. Carter]

On 3/22/21 6:13 PM, John Perry wrote:
> Hello all
> 
> I was using gnat 2020 CE on a Linux machine the other day, and wanted to write out data for three different types T1, T2, T3 to a file. I instantiated a Sequential_IO package for each; call them P1, P2, P3.
> 
> The following worked as expected (sorry for the abbreviations but I think it will be clear):
> 
>>> P1.Create; P1.Write; P1.Close; P2.Open(Append_File); P2.Write; P2.Close;

This is asking for trouble,

> 
> However, this:
> 
>>> P3.Open(Append_File); P3.Write; P3.Close;
> 
> ...wrote a few bytes of junk between T2's data and T3's data.

which you got.

When you open a P3.File_Type with mode Append_File, it expects the file to 
contain an integral number of values of T3 already. What happens if it doesn't 
appears to be undefined.

Either create a record with components of the the three types, instantiate 
Sequential_IO for that, and write all three values at once, or use streams for 
heterogeneous I/O.

-- 
Jeff Carter
"One day he told me he was a gynecologist. He
couldn't speak no foreign languages."
Take the Money and Run
147

Re: surprise data from Ada.Sequential_IO

[Dmitry A. Kazakov]

On 2021-03-22 18:13, John Perry wrote:

> I was using gnat 2020 CE on a Linux machine the other day, and wanted to write out data for three different types T1, T2, T3 to a file. I instantiated a Sequential_IO package for each; call them P1, P2, P3.
> 
> The following worked as expected (sorry for the abbreviations but I think it will be clear):
> 
>>> P1.Create; P1.Write; P1.Close; P2.Open(Append_File); P2.Write; P2.Close;
> 
> However, this:
> 
>>> P3.Open(Append_File); P3.Write; P3.Close;
> 
> ...wrote a few bytes of junk between T2's data and T3's data.
> 
> I used a hex editor to check the output file between writes, and there was no junk after P2.Close nor after P3.Open; it always came at the beginning of P3.Write.
> 
> I reworked the type definitions so that T3's data was included at the end of T2, and in this case P2.Write wrote the data properly, as desired. However, this is not the sort of permanent solution I'd want.
> 
> Has anyone else encountered this? Could this be due to alignment issues? Is there some way to avoid this without putting the data there?

I did not use Sequential_IO for decades. I doubt it was ever intended 
for the misuse you invented.

For practical point of view, I would consider this package obsolete, 
superseded by Ada.Streams.Stream_IO. It is exactly meant for your case, 
especially if you override the attributes of T1, T2, T3 (to make it 
portable).

And you are in full control of what is going on, e.g. no stuff like 
vertical formats and stupid EOF sequences.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: surprise data from Ada.Sequential_IO

[John Perry]

Jeff & Dmitry

On Monday, March 22, 2021 at 12:40:39 PM UTC-5, Jeffrey R. Carter wrote:
> On 3/22/21 6:13 PM, John Perry wrote: 
> > The following worked as expected (sorry for the abbreviations but I think it will be clear): 
> > 
> >>> P1.Create; P1.Write; P1.Close; P2.Open(Append_File); P2.Write; P2.Close;
> This is asking for trouble,
> > 
> > However, this: 
> > 
> >>> P3.Open(Append_File); P3.Write; P3.Close; 
> > 
> > ...wrote a few bytes of junk between T2's data and T3's data.
> which you got. 

Thank you, I got a laugh out of that :-)

> When you open a P3.File_Type with mode Append_File, it expects the file to 
> contain an integral number of values of T3 already. What happens if it doesn't 
> appears to be undefined. 

For Direct_IO I inferred this fact from ARM A.8.3, "the file is viewed as a set of elements occupying consecutive positions in linear order", but I don't see a similar indication for Sequential_IO. Is there a warning in the ARM about this?

(I do see the warning in Barnes' book, which I had consulted! and saw! and decided not to use Direct_IO as a result! but somehow read the same thing about Sequential_IO & either forgot or mis-concluded something. So I acknowledge my stupidity here.)

> Either create a record with components of the the three types, instantiate 
> Sequential_IO for that, and write all three values at once, or use streams for 
> heterogeneous I/O. 

I'll look into Streams, thanks.

john perry

Re: surprise data from Ada.Sequential_IO

[Jeffrey R. Carter]

On 3/22/21 7:14 PM, John Perry wrote:
> 
> For Direct_IO I inferred this fact from ARM A.8.3, "the file is viewed as a set of elements occupying consecutive positions in linear order", but I don't see a similar indication for Sequential_IO. Is there a warning in the ARM about this?
> 
> (I do see the warning in Barnes' book, which I had consulted! and saw! and decided not to use Direct_IO as a result! but somehow read the same thing about Sequential_IO & either forgot or mis-concluded something. So I acknowledge my stupidity here.)

The only differences between Direct_IO and Sequential_IO are that Direct_IO 
allows random access and mixed input and output. In both cases the file contains 
a sequence of binary representations of values of a single type.

I don't really understand why Sequential_IO exists, since Direct_IO provides a 
superset of Sequential_IO's functionality.

-- 
Jeff Carter
"One day he told me he was a gynecologist. He
couldn't speak no foreign languages."
Take the Money and Run
147

Re: surprise data from Ada.Sequential_IO

[Niklas Holsti]

On 2021-03-22 21:41, Jeffrey R. Carter wrote:

> The only differences between Direct_IO and Sequential_IO are that 
> Direct_IO allows random access and mixed input and output. In both cases 
> the file contains a sequence of binary representations of values of a 
> single type.
> 
> I don't really understand why Sequential_IO exists, since Direct_IO 
> provides a superset of Sequential_IO's functionality.

Not quite. From the RM:

    generic
       type Element_Type is private;
    package Ada.Direct_IO is
    ...

and

    generic
       type Element_Type(<>) is private;
    package Ada.Sequential_IO is
    ...

So Sequential_IO allows unknown discriminants in the element type, in 
other words elements that can vary in size, which obviously hampers 
random (indexed) access to elements in the file, which Direct_IO allows.

There is also this note for Direct_IO:

RM A.8.4(19.a): Reason: The Element_Type formal of Direct_IO does not 
have an unknown_discriminant_part (unlike Sequential_IO) so that the 
implementation can make use of the ability to declare uninitialized 
variables of the type.

Re: surprise data from Ada.Sequential_IO

[Shark8]

On Monday, March 22, 2021 at 1:41:59 PM UTC-6, Jeffrey R. Carter wrote:
> On 3/22/21 7:14 PM, John Perry wrote: 
> > 
> > For Direct_IO I inferred this fact from ARM A.8.3, "the file is viewed as a set of elements occupying consecutive positions in linear order", but I don't see a similar indication for Sequential_IO. Is there a warning in the ARM about this? 
> > 
> > (I do see the warning in Barnes' book, which I had consulted! and saw! and decided not to use Direct_IO as a result! but somehow read the same thing about Sequential_IO & either forgot or mis-concluded something. So I acknowledge my stupidity here.)
> The only differences between Direct_IO and Sequential_IO are that Direct_IO 
> allows random access and mixed input and output. In both cases the file contains 
> a sequence of binary representations of values of a single type. 
> 
> I don't really understand why Sequential_IO exists, since Direct_IO provides a 
> superset of Sequential_IO's functionality.
Going by some of the stuff where I work, most of which has foundational-stuff from the 80s and 90s (though not in Ada), the "Direct IO" is considered to be raw read/write concerning hardware or UDP datagram-packets or such. So, I would assume that by the nomenculture [and usage] of the day Direct_IO was meant for similar. Sequential_IO though sounds like a "and here we have a file full of entries of Type X, which we made generic to save ourselves the headache of maintaining multiple identical-except-for-type package."

Re: surprise data from Ada.Sequential_IO

[Jeffrey R. Carter]

On 3/22/21 9:54 PM, Niklas Holsti wrote:
> 
> Not quite. From the RM:
> 
>     generic
>        type Element_Type is private;
>     package Ada.Direct_IO is
>     ...
> 
> and
> 
>     generic
>        type Element_Type(<>) is private;
>     package Ada.Sequential_IO is

Ah, yes. Having started with Ada 83, I sometimes forget about changes like this.

-- 
Jeff Carter
"[I]f you ask, 'Why does Ada do/have this?',
the answer often makes you a better programmer."
Chad R. Meiners
177