Re: How to access this package written in C?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Keith Thompson <kst-u@mib.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> resander <kresander@gmail.com> writes:
>>
>>> On Apr 22, 10:12�pm, Keith Thompson <ks...@mib.org> wrote:
>>>> There is no guarantee that an int can hold the value of an address,
>>>> and there are common systems (including Linux systems) where it
>>>> can't. �Worse, you're not likely to get a warning if you convert
>>>> a pointer to int, even if there's a loss of information.
>>
>> Why?  I'd think if int is smaller than whatever*, then
>> a cast to int clearly deserves a warning.
>
> I made an assumption, thereby making an ass out of me and umption.

;-)

> In fact gcc does warn about converting a pointer to a smaller integer
> type:
>
>     warning: cast from pointer to integer of different size
>
> As the wording implies, it produces the same warning for a cast from a
> pointer to a larger integer type.

As well it should.

Thanks for checking gcc.  Of course I have a gcc at hand (which compiles
both Ada and C), but I was too lazy to try it.  Thanks!

> I haven't checked other C compilers.
>
> In many cases, though, C compilers tend to take a cast operator to mean
> "do this conversion and don't bother me, I know what I'm doing".

Ada is somewhat better, here, in that safer conversions
have a different syntax from unsafer conversions.

A cast, in C, might mean something fairly innocuous, or it might mean
"damn the torpedoes, full speed ahead!", and it's hard for a C compiler
to know which is which.

> [...]
>
>>> Thank you all for your concerns about using an int for passing an
>>> address. The interface actually uses a void * (could also be char * as
>>> that is what is needed), but I changed it for the post because I
>>> thought an all-int interface would be easier to handle at the Ada-to-C
>>> boundary. That seems to have backfired!
>>
>> You should look at section B (especially B.3) of the Ada RM.
>> There's a type char_star you can use.
>>
>> There's no void_star.  I'm not sure why -- probably this
>> part of Ada predates void* in C, and nobody bothered
>> to upgrade Ada to match the new C.
>
> As I recall, Ada 83 didn't have any of this; it was introduced in Ada
> 95.

Right.  Ada 83 just had pragma Interface (now called pragma Import),
and it just let implementations provide whatever interface-to-C
or interface-to-whatever they liked.  Ada 95, 2005, and 2012
offer much more.

> void* was introduced in the ANSI C standard in 1989 (reissued with
> cosmetic changes as the ISO C standard in 1990).
>
> But C still requires char* and void* to have the same representation.
>
> But in the Ada RM, I only see char_star in an example:
>
>     subtype Char_Star is Char_Ptrs.Pointer;

Yes, you're right.  My mistake -- there's no char_star in Ada.
You have to instantiate the C.Pointers generic package,
which is a bit of a pain.

On the other hand, Ada has the Interfaces.C.Strings package,
which has convenient things like char_array_access and
chars_ptr.

Note that GNAT tries pretty hard to make Ada types match
C types in representation, so if you're willing to stick
with gcc to compile your Ada and C programs, it works nicely.

> [snip]
>
> The document I'm looking at is "Ada Reference Manual, ISO/IEC
> 8652:2007(E) Ed. 3", "ISO/IEC 8652:1995(E) with Technical Corrigendum 1
> and Amendment 1".  Is that the most current version?

No.  The most current standard is here:

    http://www.ada-auth.org/

after you rummage aroung a bit.  Look for the Ada 2005 version.  The
most current future to-be-standardized version (for Ada 2012) is here:

    http://www.adaic.org/standards/ada1z.html

Note that this one has no official ISO status yet.

> A few comments on Interfaces.C:

Note that you can send comments on the Ada standard to
ada-comment@ada-auth.org.  I know you are an expert on
both C and Ada, so I think your comments about Ada-interfacing-to-C
should be taken very seriously.

> plain_char is a subtype of either unsigned_char or signed_char.  In C,
> plain char is actually a distinct type, though it has the same
> representation as either unsigned char or signed char.  It would be more
> consistent to have either
>     type plain_char is new signed_char;
> or
>     type plain_char is new unsigned_char;
> depending on the implementation.

I think I disagree with that, because "distinct type"
means different things in C versus Ada, because there
are different implicit conversions in the two languages.

In C, you can freely assign amongst these types (I think),
whereas Ada is more strict.

I'm not sure about that, but in any case, we're not going
to make incompatible changes (as subtype --> type surely
would be).

> There's no need for nul, wide_nul, and char32_nul to be
> implementation-defined; they're all zero by definition:
>
>     nul : constant char := char'val(0);
>     ...
>     wide_nul : constant wchar_t := wchar_t'val(0);
>     ...
>     char32_nul : constant char32_t := char32_t'val(0);

Yes, I think that makes sense.  See also AI95-00037.

> C doesn't actually have a type corresponding to char32_t; it has
> wchar_t, but its size is implementation-defined.

So what do you think it should say?

>     Execution of Free(X) is also erroneous if the chars_ptr X was not
>     returned by New_Char_Array or New_String.
>
> It should also be mentioned that calling Free twice on the same
> pointer value is erroneous (you can do this by saving a copy of the
> pointer before the first call to Free).

Yes, I agree.

- Bob