Re: gnulib ioctl() on OS X 10.6.6 x86

[Bruno Haible]

Markus Gothe wrote:
> Code example of the bug described using gnulib's ioctl module:
> 
> #include "config.h"
> #include <stdio.h>
> #include <stdlib.h> /* For exit() */
> #include <string.h> /* For memset() */
> #include <stddef.h>
> #include <errno.h>
> #include <signal.h>
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> #include <sys/stat.h>
> #include <netinet/in.h>
> #include <net/if_arp.h>
> #include <ifaddrs.h>
> 
> #ifdef SIOCSIFLLADDR
> #include <net/if_dl.h>
> #endif
> 
> /* Use GNU xcalloc() */
> #include "xalloc.h"
> 
> /* Our definitions */
> #include "tap.h"
> 
> int set_hwaddr_tap(tap *dev, char hwaddr[ETHER_ADDR_LEN]){
>       int ret = -1;
>       dev->ifr.ifr_addr.sa_family = AF_LINK;
>       memcpy(dev->ifr.ifr_addr.sa_data, hwaddr, ETHER_ADDR_LEN);
>       GET_SA_LEN(dev->ifr.ifr_addr) = ETHER_ADDR_LEN;
> #ifdef SIOCSIFLLADDR
>       if((ret = ioctl(dev->intf_fd, SIOCSIFLLADDR, &dev->ifr)) == -1){
> #elif defined(SIOCSIFHWADDR)
>       dev->ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
>       (void)memcpy(&dev->ifr.ifr_hwaddr.sa_data, hwaddr, ETHER_ADDR_LEN);
>        GET_SA_LEN(dev->ifr.ifr_hwaddr) = ETHER_ADDR_LEN;
>       if((ret = ioctl(dev->intf_fd, SIOCSIFHWADDR, &dev->ifr)) == -1){
> #else
> #error "Check for SIOCSIFLLADDR or SIOCSIFHWADDR"
> #endif
>               perror("ioctl");
>       }
>       return ret;
> }

Looks fine. This code will call gnulib's rpl_ioctl function, which has
the prototype
    int rpl_ioctl (int fd, int request, ...);
and is defined in lib/ioctl.c to call the system's ioctl function, which
- as you say - may have the declaration
    int ioctl (int fd, unsigned long request, ...);

Did you get any warnings when compiling lib/ioctl.c with gcc and -Wall?

I have to ask again: What behaviour did you observe?

> On FreeBSD and OS X the correct definition of ioctl is 'ioctl(int fd, 
> unsigned long request, ...)'
> using 'int request' in this case mess with 64-bits pointers.

What behaviour did you observe? Could it be explained by the fact that the
system include files don't declare ioctl in the way you say?

Bruno