win32ada design question/problem

win32ada design question/problem

[Mats Weber]

I just had a look at the win32ada binding and found that I could not use
it as I would like. Lets take this function as an example:

>     function WriteFile(hFile                 : Win32.Winnt.HANDLE;
>                        lpBuffer              : Win32.LPCVOID;
>                        nNumberOfBytesToWrite : Win32.DWORD;
>                        lpNumberOfBytesWritten: Win32.LPDWORD;
>                        lpOverlapped          : Win32.Winbase.LPOVERLAPPED)
>                                                return Win32.BOOL;

>    type    DWORD      is access all ULONG; 

Now I want to call this from some procedure:

procedure P is

   bytes_Written : aliased ULONG;
   result        : Win32.bool;

begin
   result := WriteFile(..., 
                       lpNumberOfBytesWritten => bytes_Written'Access,
                       ...);
end P;

The problem is that this does not compile because of accessibility
checks (bytes_Written is less global than the access type).

Of course I can use 'Unchecked_Access to circumvent this, but then I
don't think that the binding is well designed if it requires
'Unchecked_Access all over the place in code that uses it.

The samples directory is full of examples that, in order to be able to
use'Access instead of 'Unchecked_Access, declare all parameters to Win32
as global variables, an approach that is totally incompatible with
multitasking programs.

Another problem is the use of the type

> type    PCCH       is access constant CHAR; 

to pass pointers to strings (it is used in e.g. gethostbyname). Now if I
want to use this, what should I do ? Pass an 'Unchecked_Access to the
first element of the string, and the function is going to read the whole
string ? I don't think this is very clean.

Example:

declare
   S : constant String := ...;
begin
   x := gethostbyname(s(s'first'unchecked_access));
end;

or is there a better way ?

Does the win32ada binding really have the above problems, or am I
missing something ?

Re: win32ada design question/problem

[Tom Moran]

>Of course I can use 'Unchecked_Access to circumvent this, but then I
>don't think that the binding is well designed if it requires
>'Unchecked_Access all over the place in code that uses it.
  It's not the binding that's of questionable design, it's Windows -
Win32Ada is just a thin binding to that, and Windows (based on C) uses
the equivalent of Unchecked_Access all over.  You either swallow hard
and do C-ish code with Ada syntax, or you hide it in a thicker
binding.

Re: win32ada design question/problem

[Mats Weber]

Tom Moran wrote:

> Win32Ada is just a thin binding to that, and Windows (based on C) uses
> the equivalent of Unchecked_Access all over.  You either swallow hard
> and do C-ish code with Ada syntax, or you hide it in a thicker
> binding.

I disagree. Windows was written in C, as was UNIX, and the same problems
would appear in a UNIX binding if it were done the same way (using fancy
access types).

I think the problem with this binding is the inappropriate use of
general access types, because:

- they encourage using global declarations for the parameters (and this
is actually happening: see the examples), when using 'Unchecked_Access
would be far better.

- they don't document what is actually being done, e.g. to pass a
string, you must pass an '(Unchecked_)Access to its first character,
which is definitely not the Ada way of doing things and could even be a
problem with an aggressive optimizer.

I think a binding done with System.Address for pointers and strings, and
Interfaces.C.Int for integers, would be far better. It's the way thin
bindings were done in Ada 83 and it's a method that has always worked
fine and does not have the general access type approach's problems.

Re: win32ada design question/problem

[Tom Moran]

>I think a binding done with System.Address for pointers and strings, and
>Interfaces.C.Int for integers, would be far better.
  Why exactly is X'Address preferable to X'Unchecked_Access?
  Having spent a fair amount of time in the past debugging/correcting
supposedly portable code that incorrectly assumed an access type was a
'Address, I'm rather sensitive to this issue.

Re: win32ada design question/problem

[dennison]

In article <36531538.483857@SantaClara01.news.InterNex.Net>,
  tmoran@bix.com (Tom Moran) wrote:
> >I think a binding done with System.Address for pointers and strings, and
> >Interfaces.C.Int for integers, would be far better.
>   Why exactly is X'Address preferable to X'Unchecked_Access?
>   Having spent a fair amount of time in the past debugging/correcting
> supposedly portable code that incorrectly assumed an access type was a
> 'Address, I'm rather sensitive to this issue.

Its preferable philosophicly when I don't know and don't *care* what type of
object it points to, other than possibly its size. This is often the case in C
bindings and OS calls.

With access objects I have three choices:
  o  Write one binding for each C-routine/passed object combination I will
     ever want to use.
     Clearly unacceptable.

  o  Arbitrarily pick some dummy access type to use for the C-routine, and
convert other accesses and addresses into it.
     In keeping with the C approach, but Evil. Can cause confusion for
maintainers and other readers, and thus may cause bugs in the future.

  o  Create and use some unconstrained data array access object.  Not evil.
But unchecked conversion or address_to_access_conversion is still required to
get a value of this type. Careless attempts to dereference the pointer may
cause problems due to lack of bounds information. Way more work than using
Address.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Mats Weber]

Tom Moran wrote:

>   Why exactly is X'Address preferable to X'Unchecked_Access?
>   Having spent a fair amount of time in the past debugging/correcting
> supposedly portable code that incorrectly assumed an access type was a
> 'Address, I'm rather sensitive to this issue.

X'Address works in all cases, including arrays (Strings) for example:

   S : String := "xyz" & ascii.nul;

   function C_Function (X : in System.Address);

   C_Function(S'Address);

makes it clear that you are passing the whole of S.

On the other hand,

   type String_Access is access String;

   function C_Function (X : in String_Access);

   C_Function(S'Unchecked_Access);

will sometimes not work because some compilers (and that includes GNAT)
use fat pointers for access to unconstrained arrays (I am not saying
that this is bad).

so you have to do this instead:

   C_Function(S(S'first)'Unchecked_Access);

which does not make clear that S is passed as a whole.


The second problem is that people see a compiler message like "object
has accessibility level deeper than access type" and instead of using
'Unchecked_Access, they move the declaration to the library level and
create non task safe code. I am not making this up, see the samples
directory that comes with the win32ada binding.

Re: win32ada design question/problem

[dennison]

In article <365454A8.EFCA84F9@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> Tom Moran wrote:
>
> On the other hand,
>
>    type String_Access is access String;
>
>    function C_Function (X : in String_Access);
>
>    C_Function(S'Unchecked_Access);
>
> will sometimes not work because some compilers (and that includes GNAT)
> use fat pointers for access to unconstrained arrays (I am not saying
> that this is bad).

No, not if they follow the implementation advice.

LRM B.3(63 & 67) An implementation should support the following interface
correspondences between Ada and C. ...	o  An Ada in parameter of an
access-to-object type with designated type T is passed as a t* argument to a
C function, where t is the C type corresponding to the Ada type T.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[David Botton]

I believe that GNAT complies and the example would pass a pointer to the
String appropriate for C.




Would it be necessary to say



pragma Convention (c, String_Access)?




I know that it would not be necessary in GNAT, but would it be needed for
portability?



DB

>  Mats.Weber@elca-matrix.ch wrote:
>> Tom Moran wrote:
>>
>> On the other hand,
>>
>>    type String_Access is access String;
>>
>>    function C_Function (X : in String_Access);
>>
>>    C_Function(S'Unchecked_Access);
>>
>> will sometimes not work because some compilers (and that includes GNAT)
>> use fat pointers for access to unconstrained arrays (I am not saying
>> that this is bad).
>
>No, not if they follow the implementation advice.
>
>LRM B.3(63 & 67) An implementation should support the following interface
>correspondences between Ada and C. ... o  An Ada in parameter of an
>access-to-object type with designated type T is passed as a t* argument to
a
>C function, where t is the C type corresponding to the Ada type T.
>
>
>--
>T.E.D.
>

Re: win32ada design question/problem

[David Botton]

Mats Weber wrote:

> On the other hand,
>
>    type String_Access is access String;
>
>    function C_Function (X : in String_Access);
>
>    C_Function(S'Unchecked_Access);
>
> will sometimes not work because some compilers (and that includes GNAT)
> use fat pointers for access to unconstrained arrays (I am not saying
> that this is bad).
>
> so you have to do this instead:
>
>    C_Function(S(S'first)'Unchecked_Access);
>
> which does not make clear that S is passed as a whole.
>
> The second problem is that people see a compiler message like "object
> has accessibility level deeper than access type" and instead of using
> 'Unchecked_Access, they move the declaration to the library level and
> create non task safe code. I am not making this up, see the samples
> directory that comes with the win32ada binding.

Why wouldn't you use:

function C_Function ( X : C.char_array ) returns C.Int;
-- int c_function ( char* x);

pragma Import (C, C_Function);

From my understanding it will be passed by_referrence, ie. as a char *


For other record types

type Z is record
    a : C.Int;
end record;

pragma Convention(C, Z);

procedure C_Procedure ( Y : Z );
-- void* c_procedure ( z* y );

pragma Import  (C, C_Procedure);

David Botton

Re: win32ada design question/problem

[Mats Weber]

David Botton wrote:

> Why wouldn't you use:
> 
> function C_Function ( X : C.char_array ) returns C.Int;
> -- int c_function ( char* x);
> 
> pragma Import (C, C_Function);
> 
> From my understanding it will be passed by_referrence, ie. as a char *
> [...]

That is, of course, a good idea (using Ada 95's C interface stuff),
which its guaranteed to be portable. But that is not the approach taken
for the win32ada binding, which tried its own, IMO bad, way.

The problem with Interfaces.C.Char is that it is not the same as
Standard.Character, and Char_Array is not String, so you will have to
convert all the time, despite the fact that Char = Character on 99.99%
of all platforms. A pity IMO.

Re: win32ada design question/problem

[Marin David Condic]

Mats Weber wrote:

> David Botton wrote:
>
> > Why wouldn't you use:
> >
> > function C_Function ( X : C.char_array ) returns C.Int;
> > -- int c_function ( char* x);
> >
> > pragma Import (C, C_Function);
> >
> > From my understanding it will be passed by_referrence, ie. as a char *
> > [...]
>
> That is, of course, a good idea (using Ada 95's C interface stuff),
> which its guaranteed to be portable. But that is not the approach taken
> for the win32ada binding, which tried its own, IMO bad, way.
>
> The problem with Interfaces.C.Char is that it is not the same as
> Standard.Character, and Char_Array is not String, so you will have to
> convert all the time, despite the fact that Char = Character on 99.99%
> of all platforms. A pity IMO.

I'll agree that the Win32Ada binding is pretty messy and needlessly complex.
(Why, for example, does it have one type of access to a string and another
type of access to a constant string? Does anything down in the bowels of
Win32api actually check far enought to care?)

However, it its defense, it was supposed to have been largely automatically
generated from the original Win32api C code. That at least has the advantage
that when Micro$oft changes the interface, you can more easily regenerate
the binding.

It would have been nice to get a slightly thicker binding to the interface
which simply allows one to pass the parameters as one would expect to in
Ada, then the underlying code does whatever translation is needed to get it
to work with the actual binding.

MDC
--
Marin David Condic
===========================================================
    "A government that is big enough to give you all you want is big
    enough to take it all away."

        --  Barry Goldwater
===========================================================

Re: win32ada design question/problem

[Mats Weber]

Tom Moran wrote:

>   Why exactly is X'Address preferable to X'Unchecked_Access?
>   Having spent a fair amount of time in the past debugging/correcting
> supposedly portable code that incorrectly assumed an access type was a
> 'Address, I'm rather sensitive to this issue.

Other reasons:

- It's the good old Ada 83 way that has worked for 15 years now, wo why
change ?

- Try interfacing fcntl, setsockopt or some other weird functions using
access types: these somtimes return, or take as a parameter, a pointer
that points to a type that changes depending on the function you want to
perform, which is determined by the value of another parameter. You can
certainly do this with overloading, but I am not sure this buys much in
a thin binding.

Also, using 'Address properly does _not_ imply converting System.Address
to/from access types, which is a bad idea IMO.

Re: win32ada design question/problem

[Roga Danar]

I agree completely.  The bindings I use are done in this way.

Mats Weber wrote:

> Tom Moran wrote:
>
> > Win32Ada is just a thin binding to that, and Windows (based on C) uses
> > the equivalent of Unchecked_Access all over.  You either swallow hard
> > and do C-ish code with Ada syntax, or you hide it in a thicker
> > binding.
>
> I disagree. Windows was written in C, as was UNIX, and the same problems
> would appear in a UNIX binding if it were done the same way (using fancy
> access types).
>
> I think the problem with this binding is the inappropriate use of
> general access types, because:
>
> - they encourage using global declarations for the parameters (and this
> is actually happening: see the examples), when using 'Unchecked_Access
> would be far better.
>
> - they don't document what is actually being done, e.g. to pass a
> string, you must pass an '(Unchecked_)Access to its first character,
> which is definitely not the Ada way of doing things and could even be a
> problem with an aggressive optimizer.
>
> I think a binding done with System.Address for pointers and strings, and
> Interfaces.C.Int for integers, would be far better. It's the way thin
> bindings were done in Ada 83 and it's a method that has always worked
> fine and does not have the general access type approach's problems.

--

Re: win32ada design question/problem

[dennison]

In article <364C5EDE.4F402D13@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> I just had a look at the win32ada binding and found that I could not use
> it as I would like. Lets take this function as an example:
>
> >     function WriteFile(hFile                 : Win32.Winnt.HANDLE;
> >                        lpBuffer              : Win32.LPCVOID;
> >                        nNumberOfBytesToWrite : Win32.DWORD;
> >                        lpNumberOfBytesWritten: Win32.LPDWORD;
> >                        lpOverlapped          : Win32.Winbase.LPOVERLAPPED)
> >                                                return Win32.BOOL;
(snip)
> Of course I can use 'Unchecked_Access to circumvent this, but then I
> don't think that the binding is well designed if it requires
> 'Unchecked_Access all over the place in code that uses it.

It wasn't designed at all. (by Ada folk, anway) Its a *thin* binding. If you
want something that doesn't require unchecked programming to use, then you
want a thick binding.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Stephen Leake]

dennison@telepath.com writes:

> In article <364C5EDE.4F402D13@elca-matrix.ch>,
>   Mats.Weber@elca-matrix.ch wrote:
> > I just had a look at the win32ada binding and found that I could not use
> > it as I would like. Lets take this function as an example:
> >
> > >     function WriteFile(hFile                 : Win32.Winnt.HANDLE;
> > >                        lpBuffer              : Win32.LPCVOID;
> > >                        nNumberOfBytesToWrite : Win32.DWORD;
> > >                        lpNumberOfBytesWritten: Win32.LPDWORD;
> > >                        lpOverlapped          : Win32.Winbase.LPOVERLAPPED)
> > >                                                return Win32.BOOL;
> (snip)
> > Of course I can use 'Unchecked_Access to circumvent this, but then I
> > don't think that the binding is well designed if it requires
> > 'Unchecked_Access all over the place in code that uses it.
> 
> It wasn't designed at all. (by Ada folk, anway) Its a *thin* binding. If you
> want something that doesn't require unchecked programming to use, then you
> want a thick binding.

While I agree it wasn't well designed, I don't agree you need to go to
a thick binding. The binding should use 'out' parameter modes in the
places where C uses pointers to achieve output parameters. Most
compilers will map an 'out' parameter to a C pointer, since that's
what 'by reference' means.

-- Stephe

Re: win32ada design question/problem

[Tucker Taft]

Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:
: dennison@telepath.com writes:

: > In article <364C5EDE.4F402D13@elca-matrix.ch>,
: >   Mats.Weber@elca-matrix.ch wrote:
: > > I just had a look at the win32ada binding and found that I could not use
: > > it as I would like. Lets take this function as an example:
: > >
: > > >     function WriteFile(hFile                 : Win32.Winnt.HANDLE;
: > > >                        lpBuffer              : Win32.LPCVOID;
: > > >                        nNumberOfBytesToWrite : Win32.DWORD;
: > > >                        lpNumberOfBytesWritten: Win32.LPDWORD;
: > > >                        lpOverlapped          : Win32.Winbase.LPOVERLAPPED)
: > > >                                                return Win32.BOOL;
: > (snip)
: > > Of course I can use 'Unchecked_Access to circumvent this, but then I
: > > don't think that the binding is well designed if it requires
: > > 'Unchecked_Access all over the place in code that uses it.
: > 
: > It wasn't designed at all. (by Ada folk, anway) Its a *thin* binding. If you
: > want something that doesn't require unchecked programming to use, then you
: > want a thick binding.

: While I agree it wasn't well designed, I don't agree you need to go to
: a thick binding. The binding should use 'out' parameter modes in the
: places where C uses pointers to achieve output parameters. Most
: compilers will map an 'out' parameter to a C pointer, since that's
: what 'by reference' means.

The real problem was that the Win32 API was big enough that it
wasn't feasible to do the binding by hand.  Furthermore, even
if doing it by hand, you have to know what each pointer parameter
"means."  That isn't always obvious from just the C spec,
and becoming an expert in all of these interfaces is
a big job.  For example, representing a C pointer parameter as an Ada 
'out' or 'in out' parameter is inappropriate if the C pointer is allowed
to be null.  In fact, it was the allowance for null which forced
the use of named, rather than anonymous, access types in several
places.

In any case, if someone has the time and energy to produce a 
well-thought-out thin binding, all power to you.  The Win32 binding
we produced was done using a tool, and it reflects the limitations
of the information present in a C prototype.

: -- Stephe

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: win32ada design question/problem

[dennison]

In article <ubtm7cxj0.fsf@gsfc.nasa.gov>,
  Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
>
> While I agree it wasn't well designed, I don't agree you need to go to
> a thick binding. The binding should use 'out' parameter modes in the
> places where C uses pointers to achieve output parameters. Most
> compilers will map an 'out' parameter to a C pointer, since that's
> what 'by reference' means.

Actually, according to B.3(68), that is *required* behavour. The problem with
that technique is that many C routines attach a signifigance to a incomming
value of null. You won't be able to produce such a value on the Ada side, so
some of the functionality of the C routine will be lost.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Mats Weber]

dennison@telepath.com wrote:
> 
> In article <ubtm7cxj0.fsf@gsfc.nasa.gov>,
>   Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> >
> > While I agree it wasn't well designed, I don't agree you need to go to
> > a thick binding. The binding should use 'out' parameter modes in the
> > places where C uses pointers to achieve output parameters. Most
> > compilers will map an 'out' parameter to a C pointer, since that's
> > what 'by reference' means.
> 
> Actually, according to B.3(68), that is *required* behavour. The problem with
> that technique is that many C routines attach a signifigance to a incomming
> value of null. You won't be able to produce such a value on the Ada side, so
> some of the functionality of the C routine will be lost.

And there is another, more severe problem. The C function may allocate
some memory that you must free later, e.g.

procedure P (X : out Some_Record_Type);
pragma Import(C, P);

now as you have no pointer to the returned data, you cannot free it.

I think the Ada 83 classic int + System.Address approach is better in
this case.

Re: win32ada design question/problem

[dennison]

In article <36519A6A.C07508F5@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> dennison@telepath.com wrote:
> >
> > In article <ubtm7cxj0.fsf@gsfc.nasa.gov>,
> >   Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> > >
> > > While I agree it wasn't well designed, I don't agree you need to go to
> > > a thick binding. The binding should use 'out' parameter modes in the
> > > places where C uses pointers to achieve output parameters. Most
> > > compilers will map an 'out' parameter to a C pointer, since that's
> > > what 'by reference' means.
> >
> > Actually, according to B.3(68), that is *required* behavour. The problem
with
> > that technique is that many C routines attach a signifigance to a incomming
> > value of null. You won't be able to produce such a value on the Ada side, so
> > some of the functionality of the C routine will be lost.
>
> And there is another, more severe problem. The C function may allocate
> some memory that you must free later, e.g.
>
> procedure P (X : out Some_Record_Type);
> pragma Import(C, P);
>
> now as you have no pointer to the returned data, you cannot free it.
>
> I think the Ada 83 classic int + System.Address approach is better in
> this case.
>

I'm trying to write some portable bindings to the Zlib compression library
right now, and have found myself reverting to just that. But are there
portability issues associated with System.Address? My reading of 13.7 is that
System.Address does not nessecarily map to a C pointer, and that
System.Null_Address does not nessecarily map to a C null pointer.

The "portable" alternative we are given is Interfaces.C.Pointers. But its a
real pain to use for routines where the input object could be any type.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Mats Weber]

dennison@telepath.com wrote:

> The "portable" alternative we are given is Interfaces.C.Pointers. But its a
> real pain to use for routines where the input object could be any type.

Interfaces.C.Pointers also has the nasty problem that you must use
'Unchecked_Access instead of 'Access all the time, unless you
instantiate it in the same scope as your objects.

Also, as you are interfacing Zlib, you will be dealing with untyped
pointers all the time, so I think System.Address is really the way to go.

Re: win32ada design question/problem

[Tucker Taft]

dennison@telepath.com wrote:

: ...
: I'm trying to write some portable bindings to the Zlib compression library
: right now, and have found myself reverting to just that. But are there
: portability issues associated with System.Address? My reading of 13.7 is that
: System.Address does not nessecarily map to a C pointer, and that
: System.Null_Address does not nessecarily map to a C null pointer.

: The "portable" alternative we are given is Interfaces.C.Pointers. But its a
: real pain to use for routines where the input object could be any type.

I would not worry about the portability of System.Address.
Theoretically it might be a problem, but practically,
I doubt very much whether you will run into any problems
on hosts and targets you care about.

System.Null_Address is perhaps slightly more likely to cause
portability problems, though still I suspect you are in the
0.01% case.  You could always define your own "C_Null" in some
common target-specific package, with the 99.99% reusable
default definition of System.Null_Address.

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: win32ada design question/problem

[Tom Moran]

>: System.Address does not nessecarily map to a C pointer
>I would not worry about the portability of System.Address
I know at least one Intel-targetted Ada 95 compiler that uses 48 bits
for System.Address - 16 bit segment and 32 bit offset.  It may be that
it knows that pragma Interface to C means the segment is ignored and
should be tossed - I haven't had occasion to test that.  

Re: win32ada design question/problem

[dennison]

In article <3653142f.218516@SantaClara01.news.InterNex.Net>,
  tmoran@bix.com (Tom Moran) wrote:
> >: System.Address does not nessecarily map to a C pointer
> >I would not worry about the portability of System.Address
> I know at least one Intel-targetted Ada 95 compiler that uses 48 bits
> for System.Address - 16 bit segment and 32 bit offset.  It may be that
> it knows that pragma Interface to C means the segment is ignored and
> should be tossed - I haven't had occasion to test that.

Hmmm. This is enough in and of itself to make me back off using
System.Address. However, I have to wonder what its good for, if I can't
interface to other langauges with it.

Could making this portable possibly be the subject of a future AI?


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[tmoran]

>   C_Function(S'Address);
>
>makes it clear that you are passing the whole of S.
> ....
>   C_Function(S(S'first)'Unchecked_Access);
>
>which does not make clear that S is passed as a whole.
   C_Function(Window_Name => S(S'first)'Unchecked_Access);
or
   C_Function(Control_Character => S(S'first)'Unchecked_Access);
Using a named parameter should make it clearer in either case.
A maintainer familiar with C would realize that all of S is
potentially accessible by S(S'first)'Unchecked_Access and would
have to look up C_Function to find out if it's acting on just
(S'first) or other parts of S.  Ditto S'Address.
(And of course S probably is intended to be an Interfaces.C.Char_Array,
not an Ada String.)

>- Try interfacing fcntl, setsockopt or some other weird functions using
>access types: these somtimes return, or take as a parameter, a pointer
>that points to a type that changes depending on the function you want to
>perform, which is determined by the value of another parameter. You can
>certainly do this with overloading, but I am not sure this buys much in
>a thin binding.
  This certainly happens, but relatively rarely.  I take it as yet
another argument against too-thin bindings.

>- It's the good old Ada 83 way that has worked for 15 years now, wo why
>change ?
  Actually, no. My first Ada 83 compiler used fat pointers for
unconstrained arrays and S'Address would not do what you expected in that
case - it was necessary to use S(S'first)'Address.
Tom Moran

Re: win32ada design question/problem

[dennison]

In article <731rn7$kj5@lotho.delphi.com>,
  tmoran@bix.com wrote:
> >- Try interfacing fcntl, setsockopt or some other weird functions using
> >access types: these somtimes return, or take as a parameter, a pointer
> >that points to a type that changes depending on the function you want to
> >perform, which is determined by the value of another parameter. You can
> >certainly do this with overloading, but I am not sure this buys much in
> >a thin binding.
>   This certainly happens, but relatively rarely.  I take it as yet
> another argument against too-thin bindings.

But there *has* to be a binding at this level somewhere! It might not be
directly called by most users, but it still has to be there.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Tom Moran]

>But there *has* to be a binding at this level somewhere! It might not be
>directly called by most users, but it still has to be there.
Clearly.  But also clearly such 'dirty work' should be encapsulated
inside a pretty, understandable, robust, etc box.

Re: win32ada design question/problem

[dennison]

In article <3654a7f3.11586041@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >But there *has* to be a binding at this level somewhere! It might not be
> >directly called by most users, but it still has to be there.
> Clearly.  But also clearly such 'dirty work' should be encapsulated
> inside a pretty, understandable, robust, etc box.
>

That I can agree with. The dirty work should be buried somewhere and given a
nice safe (hopefully fully-functional) interface. That's the first thing I do
when I have to make OS calls. I don't use Win32 Ada at the moment, but if I
did I'd probably just make my own high-level packages for the routines I
need, and paste the relevent Win32 bindings into the package bodies. I did
exactly that with the DDE functionality a few years ago.

If I'm not unique in that respect, perhaps it would be a good idea to set up a
place to accumulate everyone's high-level bindings. Something more ambitious
could be setup later. Simply making them available so there isn't a horrible
amount of duplication going on would be a worthy effort.

I'd consider contributing, but I don't use Win32, and I won't as long as I
can't legaly do it.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: win32ada design question/problem

[Tom Moran]

>Simply making them available so there isn't a horrible
>amount of duplication going on would be a worthy effort.
The 1997 TriAda paper I coauthored discusses high level bindings in
Ada 95 to Windows and you can see some of the results in the source
subset of Claw and its demos.  These things are reachable via
www.rrsoftware.com  (and I understand updated demos are in the hands
of the webmaster and should be up shortly).

Re: win32ada design question/problem

[Marin David Condic]

Tom Moran wrote:

> >But there *has* to be a binding at this level somewhere! It might not be
> >directly called by most users, but it still has to be there.
> Clearly.  But also clearly such 'dirty work' should be encapsulated
> inside a pretty, understandable, robust, etc box.

I'd agree - to a point. It would be nice to have a very-thick sort of binding
to the Win32api, such as CLAW, which is a shot at creating its own windows
interface paradigm. (From my casual inspection, it is a much better job than
the organically-grown Win32api!) However, if you get serious about any sort
of Win32api programming, you are going to occasionally need to go past any
thick binding right to the original source. (A little analogous to dipping
into assembler.) Here' I'd like to have a slightly meatier interface than the
Win32Ada interface which simply organized the types and parameters the way an
Ada programmer would expect to see them, then having the binding translate to
the low level Win32Ada code. Maybe we call it Win32Ada++?)

MDC

--
Marin David Condic
===========================================================
    "A government that is big enough to give you all you want is big
    enough to take it all away."

        --  Barry Goldwater
===========================================================

Re: win32ada design question/problem

[Mats Weber]

Marin David Condic wrote:

> [...] Here' I'd like to have a slightly meatier interface than the
> Win32Ada interface which simply organized the types and parameters the way an
> Ada programmer would expect to see them, then having the binding translate to
> the low level Win32Ada code. Maybe we call it Win32Ada++?)

The problem with this beautiful idea is that it is never going to
happen. Look at POSIX 1003.5: it's hard to find a working implementation
even now, years after the IEEE standard was accepted. People just can't
wait for such bindings to come out, so I think we must still produce
thin automatically generated bindings so that they become available
shortly after the product that they interface. This is especially true
for Windows, which changes very often.

Re: win32ada design question/problem

[dennison]

In article <3659963D.1D186DDF@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:

> even now, years after the IEEE standard was accepted. People just can't
> wait for such bindings to come out, so I think we must still produce
> thin automatically generated bindings so that they become available
> shortly after the product that they interface. This is especially true
> for Windows, which changes very often.

Complete thin bindings are also very useful for developing thicker bindings.
It saves a lot of time to be able to paste the relevent declaration into my
code. I usually have to change it a bit, but its a lot better than doing it
by hand from scratch.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own