* Re: Interfaces.C and void *
1999-09-22 0:00 Interfaces.C and void * Florian Weimer
@ 1999-09-22 0:00 ` Tucker Taft
1999-09-22 0:00 ` Ted Dennison
1999-09-22 0:00 ` Keith Thompson
2 siblings, 0 replies; 4+ messages in thread
From: Tucker Taft @ 1999-09-22 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Interfaces.C and void *
1999-09-22 0:00 Interfaces.C and void * Florian Weimer
1999-09-22 0:00 ` Tucker Taft
@ 1999-09-22 0:00 ` Ted Dennison
1999-09-22 0:00 ` Keith Thompson
2 siblings, 0 replies; 4+ messages in thread
From: Ted Dennison @ 1999-09-22 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Interfaces.C and void *
1999-09-22 0:00 Interfaces.C and void * Florian Weimer
1999-09-22 0:00 ` Tucker Taft
1999-09-22 0:00 ` Ted Dennison
@ 1999-09-22 0:00 ` Keith Thompson
2 siblings, 0 replies; 4+ messages in thread
From: Keith Thompson @ 1999-09-22 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread