On Tuesday 29 March 2016 15:54:52 Joseph Myers wrote:

On Tue, 29 Mar 2016, Arnd Bergmann wrote:

quoted

In glibc, I think we need to define fewer entry points, not more.
Instead of having both lseek and lseek64, only one of them should
be provided, and that should always take a 64-bit offset, calling
into the kernel with the _llseek syscall entry.

lseek64 is part of the public API, on all platforms.  It should be aliased 
to lseek where possible.

Right, makes sense.

Strictly, it would be possible to provide it in the API without it being 
part of the ABI, by arranging the headers so that calls to lseek64 result 
in objects with a reference to lseek (because it uses the off64_t typedef, 
it's not valid to declare it yourself rather than including a header that 
declares it).  I don't think it would be a good idea for a new 
sub-architecture port to try introducing such a difference from all other 
ports, however.

How do we do it then? Should we just define __USE_FILE_OFFSET64
unconditionally for all new 32-bit architectures and leave the
code dealing with 32-bit off_t/ino_t in place but unreachable, to
minimize the differences?

Or should all the obsolete types be defined the same way as their
replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE
and use the same binary implementation regardless of FILE_OFFSET_BITS?

	Arnd