This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

POSIX.1 proper has never specified ioctl.  It's only after the
latter-day merging of POSIX and SuS documents that it appears
anywhere (aside from Rationale sections) in something called POSIX.
Even in 1003.1-2008, it is marked with [OB] and [XSR], meaning it is
considered obsolescent and that it's part of the optional XSI
STREAMS extension, not part of the the base standard.

AFAIK no GNU system has ever actually supported STREAMS.
We have the headers and functions but they are mostly stubs.
On some machines, Linux assigns a system call number and we
call that, but the kernel actually just fails with ENOSYS.

So for the <stropts.h> declaration, I think supposed standards
compliance issues are largely moot.  There is no standard that
specifies <sys/ioctl.h>, which is what people actually care about.

The meaningful issues raised in the bug report have to do with
correctness on machines where 'unsigned long int' is larger than
'int'.  That's a valid issue and I tend toward changing the
declaration to 'int'.  We're really not concerned nowadays with
precise compatibility with 4.4BSD source APIs when it might conflict
with optimal utility on GNU/Linux systems, which we were in 1993.

The tilegx and mipsn64 code to explicitly sign-extend seems
misguided to me.  As Linus said in bugzilla, Linux always treats it
as a 32-bit quantity so it really should not care at all whether it
was sign-extended to 64 bits or not.  The simplest change to the
powerpc implementation (just changing the prototype and nothing
else) will (I think) result in sign-extension on powerpc64, but it
won't actually matter to the kernel (according to Linus).  However,
it will affect things like what strace shows for the argument value,
so it seems wise to cast to unsigned in the INLINE_SYSCALL use
there.  (I suspect that strace on tilegx and mipsn64 for an ioctl
with the 32nd bit set displays unhelpful values today because of
that sign-extension.)

It also doesn't matter either way to the Hurd, because all the uses
of the parameter cast it down to 'int' or 'unsigned int'.  (It's
also moot, since there is no 64-bit Hurd configuration today.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]