[WIP] BZ #14361: POSIX vs. BSD and the `ioctl' interface.

[Joseph S. Myers]

On Mon, 23 Jul 2012, Carlos O'Donell wrote:

> (b) Backwards compatibility with an interface that has been around
>     since 1993.
> 
> Can we somehow juggle (a) and (b)?
> 
> Comments?

The binary compatibility issue is that the code needs to work with 
existing binaries passing "unsigned long" values.

In most cases, ioctl is coming from syscalls.list and so the value from 
the user's code just gets passed straight through to the kernel, both 
before and after this patch, and no binary compatibility issue arises.  
But where ioctl is implemented in C, you need to make sure there is no 
issue with a caller passing an "unsigned long" value passing a register 
value that would not be possible for an "int" argument, so causing 
undefined behavior in the C code.  In particular, what does the powerpc64 
ABI say about any required extension of incoming "int" arguments to C 
functions?

> diff --git a/ports/sysdeps/unix/sysv/linux/mips/mips64/n64/ioctl.S b/ports/sysdeps/unix/sysv/linux/mips/mips64/n64/ioctl.S
> index 3ff0d0e..1cb3541 100644
> --- a/ports/sysdeps/unix/sysv/linux/mips/mips64/n64/ioctl.S
> +++ b/ports/sysdeps/unix/sysv/linux/mips/mips64/n64/ioctl.S
> @@ -1,4 +1,4 @@
> -/* Copyright 2003, 2005 Free Software Foundation, Inc.
> +/* Copyright 2003-2012 Free Software Foundation, Inc.
>     This file is part of the GNU C Library.
>  
>     The GNU C Library is free software; you can redistribute it and/or
> @@ -19,6 +19,9 @@
>  
>  #include <sys/asm.h>
>  
> +/* FIXME: Now that the userspace API claims that the argument
> +          if of type `int' does this code need updating?  */
> +

Sign extension is just as relevant, for old binaries (together with 
kernels predating SYSCALL_WRAPPERS, anyway), as it was before.

-- 
Joseph S. Myers
joseph@codesourcery.com