Trying to import a C function

Trying to import a C function

[Preben Randhol]

Hi

Firstly I didn't manage to get florist (posix binding) to compile so
that is why I'm trying to bind this myself.

I only want to use the C stat function to find the modification date and
access time of files.

   int stat(const char *file_name, struct stat *buf);

My question is about the struct the stat function returns.

     struct stat {
         dev_t         st_dev;      /* device */
         ino_t         st_ino;      /* inode */
         mode_t        st_mode;     /* protection */
         nlink_t       st_nlink;    /* number of hard links */
         uid_t         st_uid;      /* user ID of owner */
         gid_t         st_gid;      /* group ID of owner */
         dev_t         st_rdev;     /* device type (if inode device) */
         off_t         st_size;     /* total size, in bytes */
         blksize_t     st_blksize;  /* blocksize for filesystem I/O */
         blkcnt_t      st_blocks;   /* number of blocks allocated */
         time_t        st_atime;    /* time of last access */
         time_t        st_mtime;    /* time of last modification */
         time_t        st_ctime;    /* time of last status change */
     };

After much digging I found:

   /usr/include/sys/types.h:

      typedef __dev_t dev_t;

   /usr/include/bits/types.h:

      typedef __DEV_T_TYPE __dev_t; 

   /usr/include/bits/typesizes.h:

      #define __DEV_T_TYPE           __UQUAD_TYPE

   /usr/include/bits/types.h:

      #define    __UQUAD_TYPE            unsigned long long int


So in short

      typedef unsigned long long int dev_t;

right?

Now what is the equivalent of unsigned long long int in Ada?

I don't find the info from florist, becuase it looks like you have to
manage to compile it to generate the sources needed.

System: Debian GNU/Linux on i686

Thanks in advance.

Preben

--------------------------
Compile error from florist:

gcc -O2 -DVERSION="\"Florist-3.15p  (20020604)\"" -DLIBS="\"-lresolv -lnsl -lrt -lpthread \"" -o c-posix c-posix.c -lresolv -lnsl -lrt -lpthread
c-posix.c:6347:17: missing terminating " character
c-posix.c: In function `create_c':
c-posix.c:6348: error: syntax error before "POSIX_String"
c-posix.c:6348: error: stray '\' in program
c-posix.c:6348:32: missing terminating " character
c-posix.c:6349: error: `n' undeclared (first use in this function)
c-posix.c:6349: error: (Each undeclared identifier is reported only once
c-posix.c:6349: error: for each function it appears in.)
make: *** [c-posix] Error 1

Re: Trying to import a C function

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Now what is the equivalent of unsigned long long int in Ada?

type ulonglong is mod 2**64;

> System: Debian GNU/Linux on i686

   type dev_t is new ushort;
   type nlink_t is new ushort;
   type stat_t is record
      st_dev     : dev_t;
      st_ino     : inode_t;
      st_mode    : mode_t;
      st_nlink   : nlink_t;
      st_uid     : uid_t;
      st_gid     : gid_t;
      st_rdev    : dev_t;
      st_size    : off_t;
      st_blksize : ulong;
      st_blocks  : ulong;
      st_atime   : time_t;
      st_mtime   : time_t;
      st_ctime   : time_t;
   end record;
   for stat_t use record
      st_dev     at 0 range 0 .. ushort'Size - 1;
      st_ino     at 2 * short'Size / 8 range 0 .. ulong'Size  - 1;
      st_mode    at (2*short'Size +  1*long'Size)/8 range 0 .. ushort'Size - 1;
      st_nlink   at (3*short'Size +  1*long'Size)/8 range 0 .. ushort'Size - 1;
      st_uid     at (4*short'Size +  1*long'Size)/8 range 0 .. ushort'Size - 1;
      st_gid     at (5*short'Size +  1*long'Size)/8 range 0 .. ushort'Size - 1;
      st_rdev    at (6*short'Size +  1*long'Size)/8 range 0 .. ushort'Size - 1;
      st_size    at (8*short'Size +  1*long'Size)/8 range 0 .. ulong'Size  - 1;
      st_blksize at (8*short'Size +  2*long'Size)/8 range 0 .. ulong'Size  - 1;
      st_blocks  at (8*short'Size +  3*long'Size)/8 range 0 .. ulong'Size  - 1;
      st_atime   at (8*short'Size +  4*long'Size)/8 range 0 .. ulong'Size  - 1;
      st_mtime   at (8*short'Size +  6*long'Size)/8 range 0 .. ulong'Size  - 1;
      st_ctime   at (8*short'Size +  8*long'Size)/8 range 0 .. ulong'Size  - 1;
   end record;
   for stat_t'Size use 8 * short'Size + 12 * long'Size;
   type stat_p is access all stat_t; for stat_p'Size use long'Size;

Re: Trying to import a C function

[Preben Randhol]

On 2003-11-06, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> * Preben Randhol wrote:
>> Now what is the equivalent of unsigned long long int in Ada?
>
> type ulonglong is mod 2**64;

Thanks

>> System: Debian GNU/Linux on i686
>
>    type dev_t is new ushort;

Isn't dev_t a ulonglong?

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Trying to import a C function

[Adrian Knoth]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:

>>    type dev_t is new ushort;
> Isn't dev_t a ulonglong?

sys/types.h:
typedef __dev_t dev_t;

bits/types.h:
typedef __u_quad_t __dev_t;             /* Type of device numbers.  */
__extension__ typedef unsigned long long int __u_quad_t;

So to say, dev_t is ulonglong.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Kindermund tut Kotze kund.

Re: Trying to import a C function

[Preben Randhol]

On 2003-11-07, Adrian Knoth <adi@thur.de> wrote:
> Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
>
>>>    type dev_t is new ushort;
>> Isn't dev_t a ulonglong?
>
> sys/types.h:
> typedef __dev_t dev_t;
>
> bits/types.h:
> typedef __u_quad_t __dev_t;             /* Type of device numbers.  */
> __extension__ typedef unsigned long long int __u_quad_t;
>
> So to say, dev_t is ulonglong.

Yes. Lutz wrote:

   type dev_t is new ushort;

so that is why I was wondering.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Trying to import a C function

[Lutz Donnerhacke]

* Preben Randhol wrote:
> On 2003-11-06, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>>> System: Debian GNU/Linux on i686
>>
>>    type dev_t is new ushort;
> 
> Isn't dev_t a ulonglong?

Not in my kernel sources.

Re: Trying to import a C function

[Preben Randhol]

On 2003-11-10, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> * Preben Randhol wrote:
>> On 2003-11-06, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>>>> System: Debian GNU/Linux on i686
>>>
>>>    type dev_t is new ushort;
>> 
>> Isn't dev_t a ulonglong?
>
> Not in my kernel sources.

Where is it defined?

Anyway when trying to call the stat I get a STORAGE_ERROR. I managed to
compile florist now and it seems to work with florist. :-)

Thanks all for help.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Trying to import a C function

[Adrian Knoth]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:

>>>>    type dev_t is new ushort;
>>> Isn't dev_t a ulonglong?
>> Not in my kernel sources.
> Where is it defined?

He's right, we both looked at dev_t from glibc. The kernel
defines it as __u32 in /usr/src/linux/include/linux/types.h
which is unsigned int.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Leute, die mehr als ein xterm offen haben, kann man ja wohl sowieso
nicht ernst nehmen.      (Felix von Leitner in dcoul-tng@socha.net)

Re: Trying to import a C function

[Steve]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnbqk7aq.q3.randhol+valid_for_reply_from_news@kiuk0156.chembio.ntnu.no...
> Hi
[snip]
>
> Now what is the equivalent of unsigned long long int in Ada?
>

In GNAT on x86:

  unsigned long long   =  Interfaces.Unsigned_64

You could define your own using a modular type definition, but isn't that
the reason the Interfaces module is there in the first place?

Steve
(The Duck)

> I don't find the info from florist, becuase it looks like you have to
> manage to compile it to generate the sources needed.
>
> System: Debian GNU/Linux on i686
>
> Thanks in advance.
>
> Preben
>
> --------------------------
> Compile error from florist:
>
> gcc -O2 -DVERSION="\"Florist-3.15p
 (20020604)\"" -DLIBS="\"-lresolv -lnsl -lrt -lpthread \"" -o c-posix
c-posix.c -lresolv -lnsl -lrt -lpthread
> c-posix.c:6347:17: missing terminating " character
> c-posix.c: In function `create_c':
> c-posix.c:6348: error: syntax error before "POSIX_String"
> c-posix.c:6348: error: stray '\' in program
> c-posix.c:6348:32: missing terminating " character
> c-posix.c:6349: error: `n' undeclared (first use in this function)
> c-posix.c:6349: error: (Each undeclared identifier is reported only once
> c-posix.c:6349: error: for each function it appears in.)
> make: *** [c-posix] Error 1

Re: Trying to import a C function

[Warren W. Gay VE3WWG]

Steve wrote:
> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
> message
> news:slrnbqk7aq.q3.randhol+valid_for_reply_from_news@kiuk0156.chembio.ntnu.no...
> 
>>Hi
> 
> [snip]
> 
>>Now what is the equivalent of unsigned long long int in Ada?
> 
> In GNAT on x86:
> 
>   unsigned long long   =  Interfaces.Unsigned_64
> 
> You could define your own using a modular type definition, but isn't that
> the reason the Interfaces module is there in the first place?
> 
> Steve
> (The Duck)

I find that it is generally easier, and more portable, to handle
macros and size differences in a C wrapper function. This
particularly applies to Linux, since so much changes there still.

If you enforce a parameter size of 64 bits between your C wrapper
and the Ada code, you can always be assured that you won't get
burned on the size differences.

Furthermore, if you are targeting multiple platforms/UNIces, then
the structure definition, its padding and alignment will also
give you trouble (and in fact this can potentially be the case
with different Linux releases/distros). For this reason, it is
sometimes better to have the C wrapper take the structure
elements and pass them back to Ada in safe sized arguments
individually (or perhaps stable structure definitions that
guarantee sizes and alignments).

If you use the C wrapper approach, you have a better chance of
only visiting that code once. If you choose to avoid the
wrapper, you'll likely be looking at the interface again,
with the next release or platform. ;-)

The only other alternative is to run a process that generates
the interface (or interface parameters) prior to compiling. I
believe that FLORIST does something along this line (but
it has been a while since I have looked at that side of
things).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Trying to import a C function

[Preben Randhol]

On 2003-11-06, Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> I find that it is generally easier, and more portable, to handle
> macros and size differences in a C wrapper function. This
> particularly applies to Linux, since so much changes there still.

Do you have a code example of this? Would be nice to see.

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Trying to import a C function

[Warren W. Gay VE3WWG]

Preben Randhol wrote:

> On 2003-11-06, Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> 
>>I find that it is generally easier, and more portable, to handle
>>macros and size differences in a C wrapper function. This
>>particularly applies to Linux, since so much changes there still.
> 
> 
> Do you have a code example of this? Would be nice to see.
> 
> Preben

Download my APQ project (see home page below), and look at the
process I used for adapting to MySQL. I run a combination of
scripts, and compile small C programs to generate Ada spec
packages from C macro constants. I also use a c_mysql.c module
to interface between APQ.MySQL.Client.adb and MySQL's C
libraries. This was necessary with MySQL, because some things
in MySQL require you to work with structure pointers to
members within. I didn't want to rely on structure padding
and offsets not to change etc.

There is a prominent link for APQ on my home page.

Hope that helps, Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Trying to import a C function

[Preben Randhol]

On 2003-11-10, Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> Download my APQ project (see home page below), and look at the
> process I used for adapting to MySQL. I run a combination of
> scripts, and compile small C programs to generate Ada spec
> packages from C macro constants. I also use a c_mysql.c module
> to interface between APQ.MySQL.Client.adb and MySQL's C
> libraries. This was necessary with MySQL, because some things
> in MySQL require you to work with structure pointers to
> members within. I didn't want to rely on structure padding
> and offsets not to change etc.

Thanks. Will have a look!

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."