Hi!
> >> I also wonder if it's OK to pass int value to ioctl() at all, the arg
> >> value seems to be unsigned long in the syscall definition in fs/ioctl.c
> >> and there does not seem to be any glibc magic around the syscall.
>
> This shouldn't matter, if you pass an 'int' into a function that takes
> a 'long', it will be extended if necessary. The question is more about
> how it gets interpreted, and in this case it's done by assigning to
I guess that it may, since the ioctl() prototype is defined with ...
>From /usr/include/sys/ioctl.h:
...
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;
...
Looking at dissasembly we do:
4005bb: 89 c7 mov %eax,%edi
(%eax holds fd from open())
...
4005bb: 89 c7 mov %eax,%edi
4005bd: ba 00 02 00 00 mov $0x200,%edx
^
We do 32bit load here
4005c2: be 62 12 00 00 mov $0x1262,%esi
4005c7: 31 c0 xor %eax,%eax
4005c9: e8 72 ff ff ff callq 400540 <ioctl@plt>
The ioctl assembly just sets %eax and then syscall.
So as far as I can tell we depend here on a fact that upper part of $rdx
is zeroed. Not sure if that is guaranteed or not.
--
Cyril Hrubis
chrubis@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
