Interfacing to C and long long data type

Interfacing to C and long long data type

[Maciej Sobczak]

C has a long long data type, which is supposed to be at least as big
as long. Recently, the same data type is being added to C++ as well
(they were working on it for a long long time).

The problem is that there is no corresponding type in Interfaces.C.

Is it possible to interface with C APIs that use long long?

Similar issue exists with long long double.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Interfacing to C and long long data type

[Keith Thompson]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> C has a long long data type, which is supposed to be at least as big
> as long. Recently, the same data type is being added to C++ as well
> (they were working on it for a long long time).

In addition, long long is required to be at least 64 bits wide (long
is required to be at least 32 bits wide).

> The problem is that there is no corresponding type in Interfaces.C.
> 
> Is it possible to interface with C APIs that use long long?

You can declare

    type C_Long_Long is range -2**63 .. 2**63-1;

It's not guaranteed to match C's long long, but I've never heard of a
C implementation where long long is anything other than exactly 64
bits.

There's also "unsigned long long", which you can declare in Ada as:

    type C_Unsigned_Long_Long is mod 2**64;

Note that "long long" and "unsigned long long" were introduced in the
1999 ISO C standard, which is fully implemented by only a handful of C
compilers.  Many pre-C99 compilers support "long long" as an
extension, but there are still some that don't.

> Similar issue exists with long long double.

Not really, because there is no "long long double" type in C or C++.
There's "long double", but that's been in C since at least the 1989
standard, and I presume there's already a corresponding type in
Interfaces.C.  (C and C++ have 3 floating-point types: "float",
"double", and "long double".)

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

Re: Interfacing to C and long long data type

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> C has a long long data type, which is supposed to be at least as big
> as long. Recently, the same data type is being added to C++ as well
> (they were working on it for a long long time).
>
> The problem is that there is no corresponding type in Interfaces.C.
>
> Is it possible to interface with C APIs that use long long?
>
> Similar issue exists with long long double.

GNAT's package Interfaces has Integer_64, IEEE_Extended_Float ..

Re: Interfacing to C and long long data type

[Maciej Sobczak]

On 25 Cze, 18:55, Keith Thompson <ks...@mib.org> wrote:

> You can declare
>
>     type C_Long_Long is range -2**63 .. 2**63-1;

GNAT already defines Interfaces.Integer_64, so I guess I can use that
as well. I was not sure if it would be fully legal to do so.
Considering the fact that representation of integers in C is largely
left to the implementation, any interoperability is achieved only with
the assumption that the compiler does the right thing, but with GNAT
and the C part compiled with gcc, this should be the case.

> > Similar issue exists with long long double.
>
> Not really, because there is no "long long double" type in C or C++.

Right. I wonder where I got that from. :-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Interfacing to C and long long data type

[Sébastien Morand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> GNAT already defines Interfaces.Integer_64, so I guess I can use that
> as well. I was not sure if it would be fully legal to do so.
> Considering the fact that representation of integers in C is largely
> left to the implementation, any interoperability is achieved only with
> the assumption that the compiler does the right thing, but with GNAT
> and the C part compiled with gcc, this should be the case.

Anyway when you interface Ada with C, you are loosing the portability of
your program, because you are never sure of the size of any type since C
definition of type is quite imprecise. Of course standard type match
quite well (Int, Long in ada are in the same size of int and long in C)
but when you use Integer_64, this is not.

So you have to create a configure style program checking the size of you
data and using the right one.

This is espcially true when using C structure that you have to define by
yourself:

For instance :

struct my_struct {
   int field1,
   char* field2,
   long field3
};

with Interface.C; use Interfaces.C;

package Interface.My_Structures is

   type My_Struct is record
      Field1: Int;
      Field2: System.Address;
      Field3: Long;
   end record;

end Interface.My_Structures;

But if you get a new version of my_struct using a new field. You could
get core dumped or wrong behaviour :

struct my_struct {
   int field1,
   char* field2,
   unsigned int field2_length,
   long field3
};

So be careful.

S�bastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIY1kJ+zV9xm4PlDQRAuYaAJ40/HEceKuwt2wLp0qOfc+qlBxnegCePNah
4ejBkkzVx/TmfEtzJ2Cc8mg=
=LE1d
-----END PGP SIGNATURE-----

Re: Interfacing to C and long long data type

[Georg Bauhaus]

S�bastien Morand wrote:

> Anyway when you interface Ada with C, you are loosing the portability of
> your program.

OTOH, in particular when using GNAT's native targets, there
is a good chance that you loose very little when interfacing
with C (as Maciej explains)---without proper C interfacing
there is just no Ada program when the runtime relies on C
conventions anyway. It has to, because among the facts of
life, one is that an OS is typically written in C.[*]

When your target is not native, again, chances are that
the OS infrastructure on which to build your Ada program uses
C conventions.

I won't mention the load of useful libraries that are,
unfortunately, written in &*-language. I won't be able
to use these libraries when you insist on Ada Only portability.

A better appraoch would seem to isolate the interfacing
parts and use redundant representation clauses and a handful
of tests. Running the test will not be the same as a careful
analysis of matching C/Ada representations. But at least they
can draw attention to this important issue.


-- Georg
___
[*] Another fact is that working for an investment bank and
working for an adventure game team show the same traits
and effects of addiction.  Could this play a part
in how OS software is written...

Re: Interfacing to C and long long data type

[Maciej Sobczak]

On 26 Cze, 10:53, Sébastien Morand <seb.mor...@gmail.com> wrote:

> Anyway when you interface Ada with C, you are loosing the portability of
> your program

If I need some functionality, then non-portable program that has this
functionality is infinitely better than a portable program that does
not.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Interfacing to C and long long data type

[Sébastien Morand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> If I need some functionality, then non-portable program that has this
> functionality is infinitely better than a portable program that does
> not.

I concluded in the same way for my own business :-)

Sebastien

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIZPnA+zV9xm4PlDQRAlxHAJ92EbvaGp/cfywWvqevqpDH5b8z0gCgjJA7
APlt/1/ner+HzVp2Milbp3o=
=Ao4x
-----END PGP SIGNATURE-----

Re: Interfacing to C and long long data type

[Dmitry A. Kazakov]

On Thu, 26 Jun 2008 04:59:01 -0700 (PDT), Maciej Sobczak wrote:

> On 26 Cze, 10:53, S�bastien Morand <seb.mor...@gmail.com> wrote:
> 
>> Anyway when you interface Ada with C, you are loosing the portability of
>> your program
> 
> If I need some functionality, then non-portable program that has this
> functionality is infinitely better than a portable program that does
> not.

Why infinitely? Having any functionality X can have only a finite value.
Similarly the value of having no X is also finite. [Assuming some additive
model of values.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing to C and long long data type

[Adam Beneschan]

On Jun 27, 9:11 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 26 Jun 2008 04:59:01 -0700 (PDT), Maciej Sobczak wrote:
> > On 26 Cze, 10:53, Sébastien Morand <seb.mor...@gmail.com> wrote:
>
> >> Anyway when you interface Ada with C, you are loosing the portability of
> >> your program
>
> > If I need some functionality, then non-portable program that has this
> > functionality is infinitely better than a portable program that does
> > not.
>
> Why infinitely? Having any functionality X can have only a finite value.
> Similarly the value of having no X is also finite. [Assuming some additive
> model of values.]

I think the idea here is that the value of a portable program that
does not have the functionality you need is 0.0, and so even though
the functionality of the non-portable value is finite, when you divide
to get a ratio you will get an infinite answer.  Well, actually,
you'll get Constraint_Error but that's just a nitpick......

                             -- Adam

Re: Interfacing to C and long long data type

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> I think the idea here is that the value of a portable program that
> does not have the functionality you need is 0.0, and so even though
> the functionality of the non-portable value is finite, when you
> divide to get a ratio you will get an infinite answer.  Well,
> actually, you'll get Constraint_Error but that's just a
> nitpick......

Depends on your compiler and the result type -- with GNAT, a
destination subtype of unconstrained Float will silently give you Inf
(which is invalid), whereas a destination subtype eg

   subtype F is Float range Float'First .. Float'Last

will give you Constraint_Error.

Re: Interfacing to C and long long data type

[Dmitry A. Kazakov]

On Fri, 27 Jun 2008 11:53:25 -0700 (PDT), Adam Beneschan wrote:

> On Jun 27, 9:11 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> On Thu, 26 Jun 2008 04:59:01 -0700 (PDT), Maciej Sobczak wrote:
>>> On 26 Cze, 10:53, S�bastien Morand <seb.mor...@gmail.com> wrote:
>>
>>>> Anyway when you interface Ada with C, you are loosing the portability of
>>>> your program
>>
>>> If I need some functionality, then non-portable program that has this
>>> functionality is infinitely better than a portable program that does
>>> not.
>>
>> Why infinitely? Having any functionality X can have only a finite value.
>> Similarly the value of having no X is also finite. [Assuming some additive
>> model of values.]
> 
> I think the idea here is that the value of a portable program that
> does not have the functionality you need is 0.0, and so even though
> the functionality of the non-portable value is finite, when you divide
> to get a ratio you will get an infinite answer.

This would be a multiplicative model then. It does not look any realistic.
People tend to exaggerate their expectations and requirements. Being
confronted a real choice, they behave differently from what they think or
say about it.

No feature can remove all value of a program if missing. In an additive
model of values it would mean that the feature is implied by *all*
features, existing or just possible. I doubt that any C library could ever
provide anything close to that...

> Well, actually,
> you'll get Constraint_Error but that's just a nitpick......

It won't compile, "/" is not defined on that type... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de