This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH] [BZ #19371] Properly handle x32 syscall


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. 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.

Rich


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