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

Rich


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