The "black magic" of ioctl

The "black magic" of ioctl

[Francesco Piraneo Giuliano]

Hi gentleman,

I've a nice question for you! :-)

In linux we have the ioctl function that allows to control or get
informations about an open device.

Questions:

- I have not clear if the ioctl is a function of POSIX compliant os'es
so it can be handled by ADA libflorist or is a linux-specific function
that we have to import in ADA with a PRAGMA IMPORT;

- In the case that ioctl is a standard POSIX function, I'm very glad
if someone can address me to the right function in libflorist... I've
not found anything similar.

Thank you very much for your answers.
Francesco

PS'es:

- I know it's an idiot question, for that reason I think that nobody
has difficulties to answer me! :-D

- Thank you very much to the guy that called "florist" a library for
interfacing ADA with POSIX compliant os'es!! So when I google about it
I get lot of flower's sellers called "Ada"... all around the world!

- Thank also to the guy that thought to call Ada language ... "Ada"!
May be better something like "Lovelace" or "Byron"? Just to avoid the
tons of porn related material about the various "Ada" showgirls.... :-
( (Thank you google to index also the porns...)

- I can understand also the guys that reading my post will thought:
"Hey, man!! You MUST know everything about POSIX and ADA and C and
LINUX and IEEE standard and ISO standards and...{put what you want}" -
Yeah guy! You have reason, but not everyone has so strong knowledge of
all this materials... is for that reason a nice and FOCUSED
documentation about libflorist would be interesting... saying "You
must already know" is not a nice reason to avoid to write
documentations! I work in automatic machines and the documentation is
compared as a SAFETY FEATURE of the machine itself... just to tell you
how a well written document is very important to avoid troubles...
(very often with LEGAL - i.e. -> JAIL - implications... ;-)))

Re: The "black magic" of ioctl

[Ludovic Brenta]

Francesco Piraneo Giuliano wrote:
> In linux we have the ioctl function that allows to control or get
> informations about an open device.
>
> Questions:
>
> - I have not clear if the ioctl is a function of POSIX compliant os'es
> so it can be handled by ADA libflorist or is a linux-specific function
> that we have to import in ADA with a PRAGMA IMPORT;
>
> - In the case that ioctl is a standard POSIX function, I'm very glad
> if someone can address me to the right function in libflorist... I've
> not found anything similar.

The title of your post is quite correct; ioctl is indeed black
magic :)

POSIX[1] defines this function, as "obsolescent" mind you, along with
several values of the request parameter but most operating systems add
nonstandard values to the standard ones.  Most of these values are
appropriate only for certain kinds of device.  Depending on the value
of the request parameter, ioctl performs entirely different things and
takes a different arg parameter; it is a variadic function which has
no equivalent in Ada.  So, calls to ioctl are sometimes portable (if
request has one of the standard values), sometimes non-portable across
operating systems, sometimes non-portable across devices on a single
machine, and always obsolescent!

Therefore, a thick Ada binding would not expose ioctl directly but
instead offer a different subprogram (with the appropriate parameters)
for each supported value of the request parameter.

This may explain why Florist has no binding to ioctl.  GNAT.Sockets
has one
in the body off the package but it is used for only one specific value
of
the request parameter.  So I suggest you create a binding only for the
specific purpose you need ioctl for and use that.

[1] http://www.opengroup.org/onlinepubs/9699919799/

> - Thank you very much to the guy that called "florist" a library for
> interfacing ADA with POSIX compliant os'es!! So when I google about it
> I get lot of flower's sellers called "Ada"... all around the world!

I normally look in the sources themselves, since the specs are the
most comprehensive, up-to-date and correct documentation.

> - Thank also to the guy that thought to call Ada language ... "Ada"!
> May be better something like "Lovelace" or "Byron"? Just to avoid the
> tons of porn related material about the various "Ada" showgirls.... :-
> ( (Thank you google to index also the porns...)

"+Ada +POSIX +Florist" gives good results in combination.

> - I can understand also the guys that reading my post will thought:
> "Hey, man!! You MUST know everything about POSIX and ADA and C and
> LINUX and IEEE standard and ISO standards and...{put what you want}" -
> Yeah guy! You have reason, but not everyone has so strong knowledge of
> all this materials... is for that reason a nice and FOCUSED
> documentation about libflorist would be interesting... saying "You
> must already know" is not a nice reason to avoid to write
> documentations! I work in automatic machines and the documentation is
> compared as a SAFETY FEATURE of the machine itself... just to tell you
> how a well written document is very important to avoid troubles...
> (very often with LEGAL - i.e. -> JAIL - implications... ;-)))

See [1] above for the official documentation of POSIX.  The
additional, non-standard values of "request" along with the parameter
profiles are in the ioctl_list(2) man page installed on your machine.
See that and despair...

HTH

--
Ludovic Brenta.

Re: The "black magic" of ioctl

[Francesco Piraneo Giuliano]

> The title of your post is quite correct; ioctl is indeed black
> magic :)
>
> POSIX[1] defines this function, as "obsolescent" mind you, along with
> {a big cut - save your bandwidth!}

Ok Ludovic, thank you for your great answer!

So, please don't use ioctl -> black magic -> forbidden! :-)

But my application still need to be written and has to run under linux
so to collect some data about linux' framebuffer I have to use ioctl;
the only solution is to write all low level interfacing (open the
device, get informations about, map it into memory) in C then write
the upper level in Ada?

If this is true I have some philosophical concerns about... ;-)

Any other suggestions will be strongly appreciated!

Just one question to you: Normally which OS you use with Ada?
Moreover, there is a more suited os to be driven with Ada programs?

Merci! ;-)
Francesco

Re: The "black magic" of ioctl

[Colin Paul Gloster]

Ludovic Brenta <ludovic@ludovic-brenta.org> sent on October 21st, 2010:

|------------------------------------------------------------------------|
|"Francesco Piraneo Giuliano wrote:                                      |
|[..]                                                                    |
|                                                                        |
|> - Thank you very much to the guy that called "florist" a library for  |
|> interfacing ADA with POSIX compliant os'es!! So when I google about it|
|> I get lot of flower's sellers called "Ada"... all around the world!   |
|                                                                        |
|[..]"                                                                   |
|------------------------------------------------------------------------|

Agreed. Many people do not realize that a name is supposed to denote
strictly one thing.

|------------------------------------------------------------------------|
|"> - Thank also to the guy that thought to call Ada language ... "Ada"!"|
|------------------------------------------------------------------------|

Agreed.

|------------------------------------------------------------------------|
|"> May be better something like "Lovelace" or "Byron"? Just to avoid the|
|> tons of porn related material about the various "Ada" showgirls.... :-|
|> ( (Thank you google to index also the porns...)"                      |
|------------------------------------------------------------------------|

Neither Lovelace nor Byron would be good enough.

|------------------------------------------------------------------------|
|""+Ada +POSIX +Florist" gives good results in combination.              |
|                                                                        |
|[..]"                                                                   |
|------------------------------------------------------------------------|

Searching for anything related to Ada (as I had done, when not
searching just for Florist) produces a lot of noise.

Re: The "black magic" of ioctl

[Mark Lorenzen]

On 21 Okt., 13:31, Francesco Piraneo Giuliano <fpira...@gmail.com>
wrote:

> But my application still need to be written and has to run under linux
> so to collect some data about linux' framebuffer I have to use ioctl;
> the only solution is to write all low level interfacing (open the
> device, get informations about, map it into memory) in C then write
> the upper level in Ada?

No you don't need to write anything in C.

> Any other suggestions will be strongly appreciated!

It's difficult to know your exact requirements since ioctl is a
variadic system call. Maybe you can post the equivalent C-code showing
how you call ioctl in C and then we can translate it into Ada.

- Mark L

Re: The "black magic" of ioctl

[Ludovic Brenta]

Francesco Piraneo Giuliano wrote on comp.lang.ada:
>> The title of your post is quite correct; ioctl is indeed black
>> magic :)
>
>> POSIX[1] defines this function, as "obsolescent" mind you, along with
>> {a big cut - save your bandwidth!}

You cut a bit too much...

> Ok Ludovic, thank you for your great answer!
>
> So, please don't use ioctl -> black magic -> forbidden! :-)

That's not what I wrote or meant.

> But my application still need to be written and has to run under linux
> so to collect some data about linux' framebuffer I have to use ioctl;
> the only solution is to write all low level interfacing (open the
> device, get informations about, map it into memory) in C then write
> the upper level in Ada?

No; I wrote:

>> Therefore, a thick Ada binding would not expose ioctl directly
>> but instead offer a different subprogram (with the appropriate
>> parameters) for each supported value of the request parameter.
>> [...]  So I suggest you create a binding only for the specific
>> purpose you need ioctl for and use that.

What I meant by this is:

function Fixed_Info (Framebuffer : in POSIX.IO.File_Descriptor)
  return Fixed_Framebuffer_Info
is
   function ioctl
     (Framebuffer : in POSIX.IO.File_Descriptor;
      Request     : in Interfaces.C.int;
      Result      : access Fixed_Framebuffer_Info)
     return Interfaces.C.int; -- local, specific-purpose binding
   pragma Import (C, ioctl, "ioctl");
   Result : aliased Fixed_Framebuffer_Info;
begin
   if ioctl (Framebuffer, FBIOGET_FSCREENINFO, Result'Access) /= 0
then
     raise Ioctl_Error;
   end if;
   return Result;
end Fixed_Info;

> Just one question to you: Normally which OS you use with Ada?

I use Debian GNU/Linux and occasionally Debian GNU/kFreeBSD.

> Moreover, there is a more suited os to be driven with Ada programs?

Not that I know, except maybe an OS written in Ada like Lovelace or
MaRTE OS.

> Merci! ;-)

De rien :)

--
Ludovic Brenta.

Re: The "black magic" of ioctl

[Simon Wright]

Francesco Piraneo Giuliano <fpiraneo@gmail.com> writes:

> So, please don't use ioctl -> black magic -> forbidden! :-)
>
> But my application still need to be written and has to run under linux
> so to collect some data about linux' framebuffer I have to use ioctl;
> the only solution is to write all low level interfacing (open the
> device, get informations about, map it into memory) in C then write
> the upper level in Ada?

I've never had to do this. But, for example..

Googling linux ioctl framebuffer led to a piece of code:

   struct fb_var_screeninfo vinfo;
   struct fb_fix_screeninfo finfo;
   ...
   if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
           printf("Error reading fixed information.\n");
           exit(2);
   }

   if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
           printf("Error reading variable information.\n");
           exit(3);
   }

and an Ada way (there are several alternatives) would be to create a
package Framebuffer:

   with Interfaces.C;
   package Framebuffer is

      type Fixed_Screeninfo is record
         --
      end record;
      pragma Convention (C, Fixed_Screeninfo);
      --  probably a good idea to lay out the structure precisely

      type Variable_Screeninfo is record
         --
      end record;
      pragma Convention (C, Variable_Screeninfo);

      Read_Error : exception;

      function Get_Fixed_Screeninfo
        (Fd : Interfaces.C.int) return Fixed_Screeninfo;

      --  etc

   end Framebuffer;

   package body Framebuffer is

      function Get_Fixed_Screeninfo
        (Fd : Interfaces.C.int) return Fixed_Screeninfo
      is
         function ioctl (fildes : Interfaces.C.int;
                         request : Interfaces.C.unsigned_long;
                         finfo : access Fixed_Screeninfo) return Interfaces.C.int;
         pragma Import (C, ioctl, "ioctl");
         FBIOGET_FSCREENINFO : constant Interfaces.C.unsigned_long := ???;
         --  get the appropriate value from the system headers; maybe
         --  write a tiny C program to print the value for you.
         finfo : aliased Fixed_Screeninfo;
         use type Interfaces.C.int;
      begin
         if ioctl (Fd, FBIOGET_FSCREENINFO, finfo'Access) /= 0 then
            raise Read_Error;
         end if;
         return finfo;
      end Get_Fixed_Screeninfo;

      --  etc

   end Framebuffer;

Re: The "black magic" of ioctl

[Julian Leyh]

> - Thank you very much to the guy that called "florist" a library for
> interfacing ADA with POSIX compliant os'es!! So when I google about it
> I get lot of flower's sellers called "Ada"... all around the world!

Too unspecific search query...

> - Thank also to the guy that thought to call Ada language ... "Ada"!
> May be better something like "Lovelace" or "Byron"? Just to avoid the
> tons of porn related material about the various "Ada" showgirls.... :-
> ( (Thank you google to index also the porns...)

Turn on strict SafeSearch!

Re: The "black magic" of ioctl

[Simon Wright]

Julian Leyh <julian@vgai.de> writes:

>> - Thank you very much to the guy that called "florist" a library for
>> interfacing ADA with POSIX compliant os'es!! So when I google about it
>> I get lot of flower's sellers called "Ada"... all around the world!
>
> Too unspecific search query...
>
>> - Thank also to the guy that thought to call Ada language ... "Ada"!
>> May be better something like "Lovelace" or "Byron"? Just to avoid the
>> tons of porn related material about the various "Ada" showgirls.... :-
>> ( (Thank you google to index also the porns...)
>
> Turn on strict SafeSearch!

I seem to have that on. No porn, but I do get the Association of
Drainage Authorities (www.ada.org.uk)!!!

Re: The "black magic" of ioctl

[Randy Brukardt]

"Francesco Piraneo Giuliano" <fpiraneo@gmail.com> wrote in message 
news:acb50562-4a4b-42ee-bfa8-d65c182831d8@c20g2000yqj.googlegroups.com...
...
> - Thank also to the guy that thought to call Ada language ... "Ada"!
> May be better something like "Lovelace" or "Byron"? Just to avoid the
> tons of porn related material about the various "Ada" showgirls.... :-
> ( (Thank you google to index also the porns...)

Ada was named long before there was any web or Google, so that could hardly 
have been a consideration. :-)

In any case, the AdaIC has a search engine that searches most sites that 
have Ada content and nothing else. If you're having trouble with Google, 
give it a try. Find it at:

http://www.adaic.com/site/wide-search.html

(BTW: This page may move to a different location on the new AdaIC site, 
which is coming soon. Most pages will be forwarded to their new locations, 
but there is always the possibility of it getting broken.)

                                    Randy.

Re: The "black magic" of ioctl

[Francesco Piraneo Giuliano]

On 21 Ott, 22:45, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Ada was named long before there was any web or Google, so that could hardly
> have been a consideration. :-)

Hi Randy,

I know, I know! :-D Just joking and complains about the tons of porns
and trash websites... Is the dark side of internet! :-(

By the way thank to my complain now I have another website to
explore! ;-)

Francesco

Re: The "black magic" of ioctl

[Francesco Piraneo Giuliano]

Hi Ludovic,

I already posted an answer yesterday but it seems that the post was
lost! I'll write down again!

> >> POSIX[1] defines this function, as "obsolescent" mind you, along with
> >> {a big cut - save your bandwidth!}
>
> You cut a bit too much...

Nothing is lost forever! :-D

> > Ok Ludovic, thank you for your great answer!
>
> > So, please don't use ioctl -> black magic -> forbidden! :-)
>
> That's not what I wrote or meant.

Yes, it's true! Just I'm not comfortable to use "obsolescent" things
and I hoped that on the opengroup website I could find a suitable
replacement function... that's not true unfortunately, they only
marked "obsolescent" but actually we don't have any replacement
function: we have to import the ioctl as you suggested on your post
(that is the most logic choice too).

> > Just one question to you: Normally which OS you use with Ada?
>
> I use Debian GNU/Linux and occasionally Debian GNU/kFreeBSD.
>
> > Moreover, there is a more suited os to be driven with Ada programs?
>
> Not that I know, except maybe an OS written in Ada like Lovelace or
> MaRTE OS.

With these fews rows you gave me more interesting materials to study
about! ;-)

A+
Francesco

Re: The "black magic" of ioctl

[Francesco Piraneo Giuliano]

Hi Ludovic,

I already posted an answer yesterday but it seems that the post was
lost! I'll write down again!

> >> POSIX[1] defines this function, as "obsolescent" mind you, along with
> >> {a big cut - save your bandwidth!}
>
> You cut a bit too much...

Nothing is lost forever! :-D

> > Ok Ludovic, thank you for your great answer!
>
> > So, please don't use ioctl -> black magic -> forbidden! :-)
>
> That's not what I wrote or meant.

Yes, it's true! Just I'm not comfortable to use "obsolescent" things
and I hoped that on the opengroup website I could find a suitable
replacement function... that's not true unfortunately, they only
marked "obsolescent" but actually we don't have any replacement
function: we have to import the ioctl as you suggested on your post
(that is the most logic choice too).

> > Just one question to you: Normally which OS you use with Ada?
>
> I use Debian GNU/Linux and occasionally Debian GNU/kFreeBSD.
>
> > Moreover, there is a more suited os to be driven with Ada programs?
>
> Not that I know, except maybe an OS written in Ada like Lovelace or
> MaRTE OS.

With these fews rows you gave me more interesting materials to study
about! ;-)

A+
Francesco

Re: The "black magic" of ioctl

[michael bode]

Am 21.10.2010 13:31, schrieb Francesco Piraneo Giuliano:

> But my application still need to be written and has to run under linux
> so to collect some data about linux' framebuffer I have to use ioctl;
> the only solution is to write all low level interfacing (open the
> device, get informations about, map it into memory) in C then write
> the upper level in Ada?


Look here http://www.pegasoft.ca/resources/boblap/book.html for
information on how to program for Linux in Ada. You can call ioctl from
an Ada program, you only have to arrange the parameters. For example
this is part of a thin binding to Vide4Linux2 API:

with Posix.Io;
with Interfaces.C;
with Interfaces.C.Strings;

private package Video_4_Linux_2.Ioctls is

   package C renames Interfaces.C;
   VIDIOC_QUERYCAP : constant := -2140645888;

...

   type C_V4l2_Capability is record
      Driver       : C.Char_Array(0 .. 15);
      Card         : C.Char_Array(0 .. 31);
      Bus_Info     : C.Char_Array(0 .. 31);
      Version      : Unsigned32;
      Capabilities : Bits32;
      Reserved     : U32_Array(0 .. 3);
   end record;

   pragma Convention (C, C_V4l2_Capability);

   function Ioctl (Fd  : POSIX.IO.File_Descriptor;
                   Cmd : C.int;
                   Arg : access C_V4l2_Capability) return C.int;
   pragma Import (C, Ioctl, "ioctl");

And you use this ioctl like this:

   type Capability_array is array(Capability_Index) of boolean;

   type V4l2_Capability is record
      Driver : String(1 .. 16);
      Card : String(1 .. 32);
      Bus_Info : String(1 .. 32);
      Version : Natural;
      Capabilities : Capability_Array;
   end record;

   procedure Get_Capability (Device :     Video_Device;
                             Cap    : out V4l2_Capability)
   is
      C_Cap : aliased C_V4l2_Capability;
   begin
      if 0 = Ioctl (Device.Fd, VIDIOC_QUERYCAP, C_Cap'access) then
         Cap.Driver(1..C.To_Ada (C_Cap.Driver)'Length) :=
		C.To_Ada (C_Cap.Driver);
         Cap.Driver(C.To_Ada (C_Cap.Driver)'Length+1..16) :=
		(others => ' ');
...

Re: The "black magic" of ioctl

[Simon Wright]

michael bode <m.g.bode@web.de> writes:

>       if 0 = Ioctl (Device.Fd, VIDIOC_QUERYCAP, C_Cap'access) then

I recognise the point of this to-me totally counter-intuitive convention
in C, really not needed in Ada! (or Python ..)

Re: The "black magic" of ioctl

[michael bode]

Am 23.10.2010 14:13, schrieb Simon Wright:
> michael bode <m.g.bode@web.de> writes:
> 
>>       if 0 = Ioctl (Device.Fd, VIDIOC_QUERYCAP, C_Cap'access) then
> 
> I recognise the point of this to-me totally counter-intuitive convention
> in C, really not needed in Ada! (or Python ..)

You mean functions returning error codes? Or putting 0 on the left side
of the equality operator? Calling C functions from Ada is writing C in
Ada syntax. Therefore you hide it in a package that looks like Ada to
the outside.

Re: The "black magic" of ioctl

[Simon Wright]

michael bode <m.g.bode@web.de> writes:

> Am 23.10.2010 14:13, schrieb Simon Wright:
>> michael bode <m.g.bode@web.de> writes:
>> 
>>>       if 0 = Ioctl (Device.Fd, VIDIOC_QUERYCAP, C_Cap'access) then
>> 
>> I recognise the point of this to-me totally counter-intuitive convention
>> in C, really not needed in Ada! (or Python ..)
>
> You mean functions returning error codes? Or putting 0 on the left side
> of the equality operator? Calling C functions from Ada is writing C in
> Ada syntax. Therefore you hide it in a package that looks like Ada to
> the outside.

Putting 0 on the left side of the equality operator to make sure you
don't accidentally make an assignment.

Re: The "black magic" of ioctl

[michael bode]

Am 23.10.2010 18:25, schrieb Simon Wright:

> Putting 0 on the left side of the equality operator to make sure you
> don't accidentally make an assignment.

Oh, I find this sometimes more readable when you check for a certain
result than searching for the check after many characters of function
parameters.

Re: The "black magic" of ioctl

[Florian Weimer]

* Francesco Piraneo Giuliano:

> But my application still need to be written and has to run under linux
> so to collect some data about linux' framebuffer I have to use ioctl;
> the only solution is to write all low level interfacing (open the
> device, get informations about, map it into memory) in C then write
> the upper level in Ada?

ioctl is a varargs function.  You cannot call C varargs functions
directly from Ada.  You need to write a small wrapper with a fixed
number of arguments.

In addition, the ioctl constants are often difficult to extract from
the header files.  The best way to get them seems to be a small C
program which just prints them.

So writing some C code is unavoidable here.

Re: The "black magic" of ioctl

[Simon Wright]

Florian Weimer <fw@deneb.enyo.de> writes:

> In addition, the ioctl constants are often difficult to extract from
> the header files.  The best way to get them seems to be a small C
> program which just prints them.

It could print them as an Ada spec; no manual handling required!

Re: The "black magic" of ioctl

[Frank J. Lhota]

On 10/23/2010 4:26 PM, Florian Weimer wrote:
> ioctl is a varargs function.  You cannot call C varargs functions
> directly from Ada.  You need to write a small wrapper with a fixed
> number of arguments.
>
> In addition, the ioctl constants are often difficult to extract from
> the header files.  The best way to get them seems to be a small C
> program which just prints them.
>
> So writing some C code is unavoidable here.

Actually, you can call a varargs function such as ioctl from Ada. 
Declare each ioctl profile that you need, e.g.

     -- ioctl for commands with no additional arguments
     function Ioctl (Fd  : in Interfaces.C.Int;
                     Cmd : in Interfaces.C.Int)
                     return Interfaces.C.Int;
     pragma Import (C, Ioctl, "ioctl");

     -- ioctl for commands with an additional argument
     -- for returning the device status
     function Ioctl (Fd     : in Interfaces.C.Int;
                     Cmd    : in Interfaces.C.Int;
                     Status : access Interfaces.C.Int)
                     return Interfaces.C.Int;
     pragma Import (C, Ioctl, "ioctl");

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: The "black magic" of ioctl

[Florian Weimer]

* Frank J. Lhota:

> Actually, you can call a varargs function such as ioctl from
> Ada. Declare each ioctl profile that you need, e.g.

Perhaps it seems to work for you, but this is not portable.  There are
popular targets where the varargs calling convention is markedly
different from the non-varargs calling convention, such as amd64.
It might still work by accident, but all bets are off, really.

Re: The "black magic" of ioctl

[Florian Weimer]

* Simon Wright:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> In addition, the ioctl constants are often difficult to extract from
>> the header files.  The best way to get them seems to be a small C
>> program which just prints them.
>
> It could print them as an Ada spec; no manual handling required!

Sure (and I did that in similar cases).

By the way, is there a good way to integrate such source code
generation into the gnatmake project-based build system?

Re: The "black magic" of ioctl

[Simon Wright]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Frank J. Lhota:
>
>> Actually, you can call a varargs function such as ioctl from
>> Ada. Declare each ioctl profile that you need, e.g.
>
> Perhaps it seems to work for you, but this is not portable.  There are
> popular targets where the varargs calling convention is markedly
> different from the non-varargs calling convention, such as amd64.  It
> might still work by accident, but all bets are off, really.

I hadn't realised this: but a quick scan of the GNAT sources confirms:
in socket.c,

* Wrapper for ioctl(2), which is a variadic function */

int
__gnat_socket_ioctl (int fd, int req, int *arg) {
#if defined (_WIN32)
  return ioctlsocket (fd, req, arg);
#else
  return ioctl (fd, req, arg);
#endif
}

Re: The "black magic" of ioctl

[Frank J. Lhota]

On 10/24/2010 2:36 PM, Simon Wright wrote:
> Florian Weimer<fw@deneb.enyo.de>  writes:
>
> I hadn't realised this: but a quick scan of the GNAT sources confirms:
> in socket.c,
>
> * Wrapper for ioctl(2), which is a variadic function */
>
> int
> __gnat_socket_ioctl (int fd, int req, int *arg) {
> #if defined (_WIN32)
>    return ioctlsocket (fd, req, arg);
> #else
>    return ioctl (fd, req, arg);
> #endif
> }

This is because of a Microsoft portability problem; in Winsock (the 
windows socket facility), the function for performing ioctl on sockets 
is named ioctlsocket instead of ioctl. This is one of many areas where 
Winsock differs just enough from the standards to require heavy use of 
"#if" preprocessing directives to maintain portability. This is why 
Winsock is by far my least favorite part of the Win32 API. At any rate, 
this problem is not an Ada issue.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: The "black magic" of ioctl

[Frank J. Lhota]

On 10/24/2010 1:56 PM, Florian Weimer wrote:

> Perhaps it seems to work for you, but this is not portable.  There are
> popular targets where the varargs calling convention is markedly
> different from the non-varargs calling convention, such as amd64.
> It might still work by accident, but all bets are off, really.

The Microsoft documentation seems to say that varargs is _not_ markedly 
different; see

     http://msdn.microsoft.com/en-us/library/dd2wa36c%28v=VS.80%29.aspx

I will concede, however, that these Import pragmas may not be portable 
to all platforms, but that is true of Import pragmas in general. After 
all, the calling convention for ioctl can vary from platform to 
platform, not to mention which calling conventions are supported by the 
Ada compiler.

I am absolutely sure that my pragmas will not work with MS Windows, for 
an more elementary reason: Win32 / Win64 does not support the ioctl 
function at all! Instead, the function DeviceIoControl is used to query 
configure most devices, and the function ioctlsocket is used to query / 
configure sockets. See

      http://msdn.microsoft.com/en-us/library/aa363216.aspx
      http://msdn.microsoft.com/en-us/library/ms738573%28VS.85%29.aspx

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: The "black magic" of ioctl

[Yannick Duchêne (Hibou57)]

Le Thu, 21 Oct 2010 12:20:23 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> [1] http://www.opengroup.org/onlinepubs/9699919799/
Many thanks for that valuable resource. Did not suspected these docs was  
publicly available.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: The "black magic" of ioctl

[Florian Weimer]

* Frank J. Lhota:

> On 10/24/2010 1:56 PM, Florian Weimer wrote:
>
>> Perhaps it seems to work for you, but this is not portable.  There are
>> popular targets where the varargs calling convention is markedly
>> different from the non-varargs calling convention, such as amd64.
>> It might still work by accident, but all bets are off, really.
>
> The Microsoft documentation seems to say that varargs is _not_
> markedly different; see
>
>     http://msdn.microsoft.com/en-us/library/dd2wa36c%28v=VS.80%29.aspx

There are additional requirements for passing floating-point
arguments.  It's different from Linux that this will only bite you
when you actually pass floating-point arguments which are used in the
callee in a certain way (which should happen with ioctl).