Re: Can we drop upstream Linux x32 support?

On 13/12/2018 17:02, Rich Felker wrote:

On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:

quoted

I can't say anything about the syscall interface. However, what I do know
is that the weird combination of a 32-bit userland with a 64-bit kernel
interface is sometimes causing issues. For example, application code usually
expects things like time_t to be 32-bit on a 32-bit system. However, this

IMHO this just historically grown (as in "it has been forever that way"
- it sounds way better in Viennese dialect though;-).

quoted

isn't the case for x32 which is why code fails to build.

I don't see any basis for this claim about expecting time_t to be
32-bit. I've encountered some programs that "implicitly assume" this
by virtue of assuming they can cast time_t to long to print it, or
similar. IIRC this was an issue in busybox at one point; I'm not sure
if it's been fixed. But any software that runs on non-Linux unices has
long been corrected. If not, 2038 is sufficiently close that catching
and correcting any such remaining bugs is more useful than covering
them up and making the broken code work as expected.

Yup, unconditionally providing 64bit
time_t/timespec/timeval/...-equivalents with libc and syscall support
also for 32bit architectures (and deprecating all 32bit versions) should
be the way to go.

FWIW I have
----  snip  ----
#if defined __x86_64__
# if defined __ILP32__		// x32
#  define PRI_time_t	"lld"	// for time_t
#  define PRI_nsec_t	"lld"	// for tv_nsec in struct timespec
# else				// x86_64
#  define PRI_time_t	"ld"	// for time_t
#  define PRI_nsec_t	"ld"	// for tv_nsec in struct timespec
# endif
#else				// i[3-6]68
# define PRI_time_t	"ld"	// for time_t
# define PRI_nsec_t	"ld"	// for tv_nsec in struct timespec
#endif
----  snip  ----
in my userspace code for printf() and friends - I don't know how libc's
react to such a patch (and I don't care for the name of the macros as
long it's obviously clear for which type they are).
I assume/fear we won't get additional modifiers into the relevant
standards for libc types (as they are far more like pid_t, uid_t etc.).
And casting to u/intmaxptr_t to get a defined printf()-modifier doesn't
look appealing to me to "solve" such issues.

MfG,
	Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
    - Linus Torvalds