This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [WIP] BZ #14361: POSIX vs. BSD and the `ioctl' interface.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos_odonell at mentor dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha<libc-alpha at sourceware dot org>, Chris Metcalf <cmetcalf at tilera dot com>
- Date: Tue, 24 Jul 2012 14:34:58 +0000
- Subject: Re: [WIP] BZ #14361: POSIX vs. BSD and the `ioctl' interface.
- References: <500E1CA6.7050607@mentor.com>
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