Interfaces.C and void *

Interfaces.C and void *

[Florian Weimer]

Recently, I wrote a binding for a C library which provides an abstract
data type and completely hides the underlying representation of the type
(i.e., all the public routines work on pointers to void).

Is there really no portable equivalent of a C void * in Interfaces.C?
I used Interfaces.C.Strings.chars_ptr, which should be quite portable in
practice, but AFAIK, ISO C doesn't require the representation of void *
and char * to be identical.

Re: Interfaces.C and void *

[Tucker Taft]

Florian Weimer wrote:
> 
> Recently, I wrote a binding for a C library which provides an abstract
> data type and completely hides the underlying representation of the type
> (i.e., all the public routines work on pointers to void).
> 
> Is there really no portable equivalent of a C void * in Interfaces.C?
> I used Interfaces.C.Strings.chars_ptr, which should be quite portable in
> practice, but AFAIK, ISO C doesn't require the representation of void *
> and char * to be identical.

Adding a void_ptr to Interfaces.C would seem like a reasonable addendum
to the standard.  In the interim, I would define a type in your own
code, such as:
    type Void_Ptr is private;
   ...
    type Void_Ptr is new System.Address;

This way, you will only need to change the definition in one place
if that becomes necessary (which I doubt, in practice).

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Interfaces.C and void *

[Keith Thompson]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:
[...]
> Is there really no portable equivalent of a C void * in Interfaces.C?
> I used Interfaces.C.Strings.chars_ptr, which should be quite portable in
> practice, but AFAIK, ISO C doesn't require the representation of void *
> and char * to be identical.

Yes, it does.

ANSI/ISO 9899-1990, section 6.1.2.5, says:

    A pointer to void shall have the same representation and alignment
    requirements as a pointer to a character type.  Similarly,
    pointers to qualified or unqualified versions of compatible types
    shall have the same representation and alignment requirements.
    [Footnote: The same representation and alignment requirements are
    meant to imply interchangeability as arguments to functions,
    return values from functions, and members of unions.]  Pointers to
    other types need not have the same representation and alignment
    requirements.

Yes, a void_ptr type would be a good addition to Interfaces.C.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
"Oh my gosh!  You are SO ahead of your time!" -- anon.

Re: Interfaces.C and void *

[Ted Dennison]

In article <87btavxw93.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw@deneb.cygnus.argh.org> wrote:
> Recently, I wrote a binding for a C library which provides an abstract
> data type and completely hides the underlying representation of the
type
> (i.e., all the public routines work on pointers to void).
>
> Is there really no portable equivalent of a C void * in Interfaces.C?
> I used Interfaces.C.Strings.chars_ptr, which should be quite portable
in
> practice, but AFAIK, ISO C doesn't require the representation of void
*
> and char * to be identical.

I generally see "void *" used in two cases:
  o  A routine returns a pointer to an object whose type is determined
at runtime.
  o  The object that a routine returns is meant to be an opaque type.

In the first case it doesn't matter much what you declare as the
parameter type, as long as you use a properly mapped type when you
actually try to read the data out of the object. If clients can know
prior to the call which type it should be returning, you can even make
several bindings (one for each type).

In the second case I suspect the closest conceptual equivalent in Ada
would be System.Address. But since the C routines must typically be used
to create and delete such objects, it really doesn't matter too much
what type you choose to represent it as in Ada, as long as its the same
size.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.