Re: Sequential_Mixed_IO (DEC) for GNAT

Re: Sequential_Mixed_IO (DEC) for GNAT

[Robert Dewar]

Doug said

"If you can know of an elegant way to get access to mixed
types from a binary file, please let me know.

I heard mention of streams (?) under Ada95."

Yes, we know an elegant way, and we will be happy to let you know.
Have a look at Ada.Streams.Stream_IO.

I think you would find it more profitable to rummage around in annex A
of the RM to see if what you want is already there, rather than rummaging
around in the private runtime packages in GNAT!

Certainly you should move to Ada 95. The only reason for sticking to Ada 83
is to maintain caompatibility with Ada 83 compilers, and if you are
withing GNAT internal packages, you are abandoning that anyway.

Pure Ada 83 code will compile correctly with the -gnat83 switch in
GNAT. We do not know of exceptions to this. Of course if you start
withing internal private packages that are children of System, you
are outside Ada 83. For GNAT, the -gnat83 switch is like a 
configuration pragma, the entire program must be compild wit
this switch consistently.

Sequential_Mixed_IO (DEC) for GNAT

[Doug Rogers]

This is moved from another thread (Gripe about Ada...).

I have a requirement to use Ada83 only, 'cause it's DEC
Ada on OpenVMS AXP.  I need access to a heterogeneous
stream of data coming from a binary file.  DEC provides
a few packages for doing this "mixed" IO, one called
Sequential_Mixed_IO.  It includes a generic for getting
and putting typed data to disk.  Here are the basics of
it:

package Sequential_Mixed_IO is
  type File_Type is new System.Sequential_IO.File_Type;
  procedure Open (...);  -- all the standard file IO routines
  
  generic
    type Item_Type is private;
  procedure Get_Item (File : in File_Type; Item : out Item_Type);

  -- plus Put_Item, etc.
end Sequential_Mixed_IO;

  -- with's deleted
package body Sequential_Mixed_IO is
   -- NOTE: lots of stuff deleted
   package FIO renames System.File_IO;
   package FCB renames System.File_Control_Block;
   SU : constant := System.Storage_Unit;
   subtype AP is FCB.AFCB_Ptr;

--   generic
--      type Item_Type is private;
  procedure Get_Item
      (File : in File_Type;
       Item : out Item_Type) is
    Siz  : constant size_t := (Item'Size + SU - 1) / SU;
  begin -- Get_Item
    FIO.Check_Read_Status (AP (File));
    FIO.Read_Buf (AP (File), Item'Address, Siz);
  end Get_Item;

end Sequential_Mixed_IO;

The Open/Create procedures are NOT generic.  Now, I copied
the spec pretty much verbatim from DEC (with (c) notice!),
and then I began to implement the body.  I found that I
could only implement it by using .File_IO child package.
I simply copied the code from System.Sequential_IO.

This raised an uproar when I mentioned it on the
aforementioned thread.  "My GOD!  Someone is using a
GNAT-specific, totally unsupported, possibly changing
package for user code!"  I explained that it was prototype
code.  It works.  It allows me to do development in an
environment that's local (and not 28.8kb away).

There were calls out to make "with"-ing such packages
illegal.  Well, first the language makes it practically
impossible to get access to binary data (Sequential_IO on
a byte type doesn't cut it!), now even the low-level hacks
will be gone (yes, of course it's a hack -- conveniently
localized to only one file).

If you can know of an elegant way to get access to mixed
types from a binary file, please let me know.

I heard mention of streams (?) under Ada95.  I'll look into
that myself (I have to abandon Ada83 for my GNAT
compilations, anyway, 'cause my solution invokes a child
unit -- not allowed in Ada83 -- when the generic is
instantiated during compilation, a strictly GNAT thing).

Doug

=------cxiuj-opinioj-estas-sole-miaj.-----any-opinions-are-mine-alone.------=
= Doug Rogers      vocxe/voice = 1.703.893.2007  fakse/fax = 1.703.893.5890 =
= Innovative Concepts Inc; 8200 Greensboro Drive Suite 801; McLean VA 22102 =
= PGP ID: pub  1024/016DE91D 1994/11/14   Doug Rogers  <rogers@innocon.com> =
=senemankasalvimultodatempolernulaanglan-ifyouvegotalittletimelearnesperanto=

Re: Sequential_Mixed_IO (DEC) for GNAT

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>For GNAT, the -gnat83 switch is like a 
>configuration pragma, the entire program must be compild wit
>this switch consistently.

Just curious: why is that the case?  Does it change how data
is represented, and if so, in what way?

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

Re: Sequential_Mixed_IO (DEC) for GNAT

[Robert Dewar]

Fergus asks

">For GNAT, the -gnat83 switch is like a
>configuration pragma, the entire program must be compild wit
>this switch consistently.

Just curious: why is that the case?  Does it change how data
is represented, and if so, in what way?"

No, it changes nothing at all in the code or the data.

But didn't you start this thread? The issue is whether you can mix
ada83 and ada95 in the same program, or more accurately, since of
course that mix is ok, mix gnat units compiled with -gnat83 and 
ada 95 units in the same program. The answer, as you discovered
is sometimes no. 

We could do extra work to make -gnat83 work for this, but it is
a marginal feature anyway, and it is not worth the trouble,

Re: Sequential_Mixed_IO (DEC) for GNAT

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Fergus asks
>
>">For GNAT, the -gnat83 switch is like a
>>configuration pragma, the entire program must be compild wit
>>this switch consistently.
>
>Just curious: why is that the case?  Does it change how data
>is represented, and if so, in what way?"
>
>No, it changes nothing at all in the code or the data.

Then why can't you mix-and-match units compiled with and without -gnat83?
I'm confused.

>But didn't you start this thread?

Nope.

>The answer, as you discovered is sometimes no. 

Perhaps if I had discovered this, I would know why.  But it wasn't me.
Maybe I missed some important part of this thread which explained it.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3