Re: [PATCH] [BZ #19371] Properly handle x32 syscall

[Mike Frysinger <vapier at gentoo dot org>]

On 21 Dec 2015 17:06, Rich Felker wrote:
> On Thu, Dec 17, 2015 at 12:53:04AM +0000, Joseph Myers wrote:
> > On Wed, 16 Dec 2015, H.J. Lu wrote:
> > > > Sorry, I was talking about manual/startup.texi:
> > > >
> > > > manual/startup.texi:727:@deftypefun {long int} syscall (long int
> > > > @var{sysno}, @dots{})
> > > > manual/startup.texi-728-@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > > > manual/startup.texi-729-
> > > > manual/startup.texi-730-@code{syscall} performs a generic system call.
> > > 
> > > Here is the updated patch.  OK for master?
> > 
> > That can't possibly be right.  User documentation needs to be in terms of 
> > types exposed to the user (and documented as such), not anything starting 
> > __.
> 
> I agree, and I'm very much opposed to all the hand-waving that's been
> done with regards to breaking documented APIs by replacing long with
> __syscall_slong_t (which is not even a type that's supposed to be
> exposed to userspace) in the arguments, return types, and struct
> members of public interfaces. This makes it impossible for portable
> code using functions that may not be posix-standard, but which are
> widely known and available, to support x32 without arch-specific
> #ifdeffery nonsense.

syscall isn't portable.  it's not in POSIX, nor are the syscall numbers
used reliable across arches, nor are the func signatures.  claiming that
you don't need to worry about arch differences while also saying you can
safely use syscall directly is ridiculous.

glibc has created new types in the past.  creating a new one here doesn't
seem problematic to me.  we might also want to add a define to inttypes.h
so people have something to fallback on.  there's a number of types that
lack proper printf helpers already ...
-mike

Attachment: signature.asc
Description: Digital signature