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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |