* Re: The "black magic" of ioctl
2010-10-21 11:31 ` Francesco Piraneo Giuliano
@ 2010-10-21 11:50 ` Mark Lorenzen
2010-10-21 12:04 ` Ludovic Brenta
` (3 subsequent siblings)
4 siblings, 0 replies; 28+ messages in thread
From: Mark Lorenzen @ 2010-10-21 11:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 11:31 ` Francesco Piraneo Giuliano
2010-10-21 11:50 ` Mark Lorenzen
@ 2010-10-21 12:04 ` Ludovic Brenta
2010-10-22 16:46 ` Francesco Piraneo Giuliano
2010-10-22 16:47 ` Francesco Piraneo Giuliano
2010-10-21 12:05 ` Simon Wright
` (2 subsequent siblings)
4 siblings, 2 replies; 28+ messages in thread
From: Ludovic Brenta @ 2010-10-21 12:04 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 12:04 ` Ludovic Brenta
@ 2010-10-22 16:46 ` Francesco Piraneo Giuliano
2010-10-22 16:47 ` Francesco Piraneo Giuliano
1 sibling, 0 replies; 28+ messages in thread
From: Francesco Piraneo Giuliano @ 2010-10-22 16:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 12:04 ` Ludovic Brenta
2010-10-22 16:46 ` Francesco Piraneo Giuliano
@ 2010-10-22 16:47 ` Francesco Piraneo Giuliano
1 sibling, 0 replies; 28+ messages in thread
From: Francesco Piraneo Giuliano @ 2010-10-22 16:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 11:31 ` Francesco Piraneo Giuliano
2010-10-21 11:50 ` Mark Lorenzen
2010-10-21 12:04 ` Ludovic Brenta
@ 2010-10-21 12:05 ` Simon Wright
2010-10-22 20:16 ` michael bode
2010-10-23 20:26 ` Florian Weimer
4 siblings, 0 replies; 28+ messages in thread
From: Simon Wright @ 2010-10-21 12:05 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 11:31 ` Francesco Piraneo Giuliano
` (2 preceding siblings ...)
2010-10-21 12:05 ` Simon Wright
@ 2010-10-22 20:16 ` michael bode
2010-10-23 12:13 ` Simon Wright
2010-10-23 20:26 ` Florian Weimer
4 siblings, 1 reply; 28+ messages in thread
From: michael bode @ 2010-10-22 20:16 UTC (permalink / raw)
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 => ' ');
...
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-22 20:16 ` michael bode
@ 2010-10-23 12:13 ` Simon Wright
2010-10-23 13:27 ` michael bode
0 siblings, 1 reply; 28+ messages in thread
From: Simon Wright @ 2010-10-23 12:13 UTC (permalink / raw)
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 ..)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-23 12:13 ` Simon Wright
@ 2010-10-23 13:27 ` michael bode
2010-10-23 16:25 ` Simon Wright
0 siblings, 1 reply; 28+ messages in thread
From: michael bode @ 2010-10-23 13:27 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-23 13:27 ` michael bode
@ 2010-10-23 16:25 ` Simon Wright
2010-10-23 18:12 ` michael bode
0 siblings, 1 reply; 28+ messages in thread
From: Simon Wright @ 2010-10-23 16:25 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-21 11:31 ` Francesco Piraneo Giuliano
` (3 preceding siblings ...)
2010-10-22 20:16 ` michael bode
@ 2010-10-23 20:26 ` Florian Weimer
2010-10-24 11:08 ` Simon Wright
2010-10-24 12:41 ` Frank J. Lhota
4 siblings, 2 replies; 28+ messages in thread
From: Florian Weimer @ 2010-10-23 20:26 UTC (permalink / raw)
* 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-23 20:26 ` Florian Weimer
@ 2010-10-24 11:08 ` Simon Wright
2010-10-24 17:58 ` Florian Weimer
2010-10-24 12:41 ` Frank J. Lhota
1 sibling, 1 reply; 28+ messages in thread
From: Simon Wright @ 2010-10-24 11:08 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-24 11:08 ` Simon Wright
@ 2010-10-24 17:58 ` Florian Weimer
0 siblings, 0 replies; 28+ messages in thread
From: Florian Weimer @ 2010-10-24 17:58 UTC (permalink / raw)
* 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-23 20:26 ` Florian Weimer
2010-10-24 11:08 ` Simon Wright
@ 2010-10-24 12:41 ` Frank J. Lhota
2010-10-24 17:56 ` Florian Weimer
1 sibling, 1 reply; 28+ messages in thread
From: Frank J. Lhota @ 2010-10-24 12:41 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-24 12:41 ` Frank J. Lhota
@ 2010-10-24 17:56 ` Florian Weimer
2010-10-24 18:36 ` Simon Wright
2010-10-25 1:13 ` Frank J. Lhota
0 siblings, 2 replies; 28+ messages in thread
From: Florian Weimer @ 2010-10-24 17:56 UTC (permalink / raw)
* 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-24 17:56 ` Florian Weimer
@ 2010-10-24 18:36 ` Simon Wright
2010-10-25 0:45 ` Frank J. Lhota
2010-10-25 1:13 ` Frank J. Lhota
1 sibling, 1 reply; 28+ messages in thread
From: Simon Wright @ 2010-10-24 18:36 UTC (permalink / raw)
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
}
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-24 18:36 ` Simon Wright
@ 2010-10-25 0:45 ` Frank J. Lhota
0 siblings, 0 replies; 28+ messages in thread
From: Frank J. Lhota @ 2010-10-25 0:45 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-24 17:56 ` Florian Weimer
2010-10-24 18:36 ` Simon Wright
@ 2010-10-25 1:13 ` Frank J. Lhota
2010-10-25 18:56 ` Florian Weimer
1 sibling, 1 reply; 28+ messages in thread
From: Frank J. Lhota @ 2010-10-25 1:13 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: The "black magic" of ioctl
2010-10-25 1:13 ` Frank J. Lhota
@ 2010-10-25 18:56 ` Florian Weimer
0 siblings, 0 replies; 28+ messages in thread
From: Florian Weimer @ 2010-10-25 18:56 UTC (permalink / raw)
* 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).
^ permalink raw reply [flat|nested] 28+ messages in thread