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

[Mike Frysinger <vapier at gentoo dot org>]

On 29 Dec 2015 18:21, Rich Felker wrote:
> On Tue, Dec 29, 2015 at 05:53:38PM -0500, Mike Frysinger wrote:
> > 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
> 
> I specifically meant portable across different Linux archs, not to
> other different systems.

as i said, syscall isn't even portable at that level

> But __syscall_slong_t has even crept into
> places that do not require using syscall() but which have their own
> documented (some of them even C11 and POSIX, e.g. timespec stuff)
> interfaces. This is what I'm objecting to most strongly.

that's orthogonal to updating the syscall() API.
-mike

Attachment: signature.asc
Description: Digital signature