Re: Interfacing to C and types visible to Ada

[Fionn Mac Cumhaill <invisible@hiding.from.spam>]

On Thu, 3 Jul 2008 13:35:21 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 3 Lip, 21:35, Keith Thompson <ks...@mib.org> wrote:
>
>> Study the C API and come up with a description of what the type is
>> actually used for.
>
>It is used for integers. That's the problem. :-)
>
>> I'm not sure I understand this "domainless" business.  Can you provide
>> a simple example?
>
>Sure. The C library is a database access library. It allows the user
>to transmit data of various types, which are all "domainless". One of
>these types is, well, integer. Whether it is a "room number" or
>"number of apples" depends on the actual application, but the database
>access library does not influence it. It is really an integer, having
>a value in some range. The range happens to be defined by C's int,
>which on the particular compiler is 32-bit, signed.
>

I had the same problem. In my case, the database is medical data
stored in a Microsoft SQL Server database. Most of the data is stored
as integers or fixed-length strings in a variety of lengths.

The integers and strings were both mostly used to store arbitrary
codes of various kinds which should not be confused with each other.

I made no attempt to improve the Ada representation of a C integer. I
defined types in an Ada package which abstracted the behavior that I
needed and then produced a child package for it that did the database
I/O operations.

In the final result, there was no clearly-defined correspondence
between C types and my Ada types. There would have been no point in
trying to improve the representation of a C integer in Ada; some of my
types were enumerated types used to represent what was an integer in
the database. Likewise, some character strings were translated into
enumerated types.

My "domains" were a very specific fit to the contents of my database.
I don't think that there is much that can be done in general to
sharpen up a C integer for Ada use. There does not seem to be much
middle ground between a "domainless" integer and types defined to suit
a specific situation. Integer types that contain the non-negative and
positive subranges of a C integer might be useful.

In the more restricted domain of database applications, some
additional types might be useful. An integer field in a database
record might not contain an integer at all - it could contain a
database null value, which neither an Ada Integer or a C int can
represent. In my particular case, none of my arbitrary integer codes
could ever have a zero value, so a zero made a convenient
representation for a null, but this would not be generally useful.

Some kind of integer-on-steroids that can represent a null value as
well as the usual range of integer values might be useful.