Re: How to access this package written in C?

[Keith Thompson <kst-u@mib.org>]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 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.

Casts (i.e., explicit conversions) are rarely necessary in
well-written C.  (They're unfortunately common in C in general.)
Most conversions in C are performed implicitly.  All arithmetic types
are implicitly convertible to each other, and all pointer-to-object
types are implicitly convertible to and from void*.

Casts are useful when you need to override the default conversions
in an arithmetic expression, for certain kinds of arguments to
variadic functions such as printf, and when you need to play games
with pointers in non-portable code.

(That's probably more information about C than most people here are
interested in, so I'll stop now.)

>> 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.

I did.  <http://www.ada-auth.org/arm.html> has links to several versions
of the Ada 2005 RM.  "RM-Final.pdf" is byte-for-byte identical to the
version I'm using, and has the above-quoted text on the title page.

> 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.

I'll check that out, thanks.

>> 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.

Thanks, I'll do that.  I seem to recall they expect some particular
format for comments (it's been a long time since I've submitted any); is
that still the case, or should I just send free-form English text?

>> 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).

Yeah, breaking compatibility would be bad.

Still, the current situation means that this:

    P: plain_char := 0;
    S: signed_char := P;

is either valid or illegal, depending on the implementation.

It's also odd that char and plain_char are two distinct types, but
there's only so much you can do to make C and Ada work together.

>> 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?

I don't know.  C201X might have some additional support in this area
(but since even C99 isn't universally supported, I'm not sure how useful
that is).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"