How to hide instantiation of Direct_IO?

How to hide instantiation of Direct_IO?

[Dale Stanbrough]

I'ld like to develop a package on top of the rather low level Direct_IO,
but prevent access to the instantiation of Direct_IO itself. 

I could do this by instantiating direct_io in a private part of a 
package, and then declare higher level routines in child packages which 
for the most part, simply forward the work onto the equivalent direct_io
routines.

However there seems no way to declare a type Count for my higher level
package such that it has the same range as that defined in Direct_IO
(type Count is 0..implementation-defined) - I can't reference the 
private instantiation - 'cos it's private!

Is there _any_ way around this problem? The _only_ solution I can think
of is not to declare a type, and just have a rather yucky function...

	function Max_File_Size return Integer; -- truly non portable!
	
	function Size(File : My_File_Type) return Integer;



Dale

Re: How to hide instantiation of Direct_IO?

[Norman H. Cohen]

Dale Stanbrough wrote:
> 
> I'ld like to develop a package on top of the rather low level Direct_IO,
> but prevent access to the instantiation of Direct_IO itself.
> 
> I could do this by instantiating direct_io in a private part of a
> package, and then declare higher level routines in child packages which
> for the most part, simply forward the work onto the equivalent direct_io
> routines.
> 
> However there seems no way to declare a type Count for my higher level
> package such that it has the same range as that defined in Direct_IO
> (type Count is 0..implementation-defined) - I can't reference the
> private instantiation - 'cos it's private!

This is one of those relatively unusual occasions on which one misses
the ability to interleave private and public declarations, as in C++.

Why not declare an integer type with the maximal range, i.e., 

   type Count is range 0 .. System.Max_Int;

and use that?  (One drawback is that your equivalent of Set_Index will
have to include a run-time check for an index that is larger than the
underlying machinery can handle, i.e., larger than Count'Last, but there
are already such run-time checks for the file-index values passed to the
Direct_IO procedures Read and Write, as described in RM A.8.5(4) and
A.8.5(7).)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to hide instantiation of Direct_IO?

[Robert Dewar]

Norman said

<<   type Count is range 0 .. System.Max_Int>>

no, not Max_Int, there is no point in introducing 64-bit inefficiency
here. type Count is new Integer will do just fine in practice.

Re: How to hide instantiation of Direct_IO?

[Norman H. Cohen]

Robert Dewar wrote:
 
> Norman said
> 
> <<   type Count is range 0 .. System.Max_Int>>
> 
> no, not Max_Int, there is no point in introducing 64-bit inefficiency
> here. type Count is new Integer will do just fine in practice.

Perhaps for GNAT, but I believe Dale was looking for a portable
solution, and it is certainly reasonable to presume that some
implementation might use Max_Int'Last as Count'Last (or that the
implementation might use some value other than 2**63-1 for Max_Int).

A 64-bit Count type is quite plausible:  In early versions of AIX, one
of the first needs that arose for 64-bit integers was for file offsets.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to hide instantiation of Direct_IO?

[Robert Dewar]

Norman said

<<A 64-bit Count type is quite plausible:  In early versions of AIX, one
of the first needs that arose for 64-bit integers was for file offsets.>>

Sure, but this is for offsets into arbitrary files. I think you are being
quite unrealistic to assume that anyone would decide that a text file
might have more than 2 billion lines of text, or a single line longer
than 2 billion characters. The only way I can imagine an implementor
choosing to use 64-bits for count is if the machine naturally handled
64-bit integers, and type Integer was 64-bits. So I am sorry I disagree,
this is implausible, and I cannot imagine an implementor making this
decision.

Re: How to hide instantiation of Direct_IO?

[Norman H. Cohen]

Robert Dewar wrote:
 
> Norman said
> 
> <<A 64-bit Count type is quite plausible:  In early versions of AIX, one
> of the first needs that arose for 64-bit integers was for file offsets.>>
> 
> Sure, but this is for offsets into arbitrary files. I think you are being
> quite unrealistic to assume that anyone would decide that a text file
> might have more than 2 billion lines of text, or a single line longer
> than 2 billion characters. 

Who said anything about text files?  The topic of this discussion is
direct I/O, and the type Count provided by instances of Ada.Direct_IO. 
Scientific and multimedia applications with data files of potentially
more than 2 billion items are commonplace.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to hide instantiation of Direct_IO?

[Richard Kenner]

In article <3315A1BF.3C1D@watson.ibm.com> ncohen@watson.ibm.com writes:
>Who said anything about text files?  The topic of this discussion is
>direct I/O, and the type Count provided by instances of Ada.Direct_IO. 
>Scientific and multimedia applications with data files of potentially
>more than 2 billion items are commonplace.

Not only that, but consider writing an "fsck" in Ada.  There the disk
is a single file, and many disks are larger than 2GB.

Re: How to hide instantiation of Direct_IO?

[Robert Dewar]

Richard Kenner said

<<Not only that, but consider writing an "fsck" in Ada.  There the disk
is a single file, and many disks are larger than 2GB.>>

Somehow, methinks that someone writing fsck in Ada might possibly NOT
decide to use Direct_IO as the implementation vehicle :-)

Re: How to hide instantiation of Direct_IO?

[Fergus Henderson]

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

>Richard Kenner said
>
><<Not only that, but consider writing an "fsck" in Ada.  There the disk
>is a single file, and many disks are larger than 2GB.>>
>
>Somehow, methinks that someone writing fsck in Ada might possibly NOT
>decide to use Direct_IO as the implementation vehicle :-)

Why not?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: How to hide instantiation of Direct_IO?

[Robert Dewar]

iFergus said
(answering me)

<<>Somehow, methinks that someone writing fsck in Ada might possibly NOT
>decide to use Direct_IO as the implementation vehicle :-)

Why not?>>

Well my smiley was there because I did not think anyone could possibly
conceive of the idea of using Direct_IO as an implementation vehicle for
fsck.

But since I was apparently mistaken ... :-)

Direct_IO is NOT a low level interface, it is a high level abstract
interface that tells you NOTHING about how records in the file are
mapped into the underlying file structures. Yes, it MIGHT be the case
that the mapping is a simple vector (rather than, for example a hash
table), but then again, it might be perfectly reasonable to use some
kind of indexing method that represented only records that are actually
present, and that would particularly be reasonable if you are representing
variable length items. Yes, it MIGHT be the case that there are no control
bytes (what in the Fortran world used to be called green words) with each
record, but then again it is perfectly reasonable to follow a typical
COBOL style of at least having a record present indicator for each record
(indeed on some systems, it may make excellent sense to map Direct_IO
into exactly the same file structure that COBOL uses for direct files).

Any attempt to use Direct_IO for low level mucking like fsck is therefore
fundamentally flawed and highly non-portable. In practice Stream_IO using
arrays of storage elements directly is the proper level of abstraction.