[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1423687670.4203.8.camel@inria.fr>
Date: Wed, 11 Feb 2015 21:47:50 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Re: [PATCHv3 00/24] ILP32 support in ARM64
Hi,
Am Mittwoch, den 11.02.2015, 15:12 -0500 schrieb Rich Felker:
> I don't see why you want it to be long long. There is no harm in
> passing uninitialized padding to the kernel; the kernel just needs to
> do the right thing and ignore it (or avoid reading it to begin with).
> Changing the C standard in an incompatible way that invalidates
> existing code is not preferable over fixing an implementation bug in
> one implementation. Even if C16 or so changed the requirement, people
> will still be looking to C11 (and even C99) for years or decades to
> come. Alignment of code to language standards moves slowly.
I second that, padding or even other named fields is the way to go,
the standard doesn't constrain that type other than that the two
fields with the prescribed type must exist.
I'd also like to add that in all that discussion I didn't hear much of
a good reason to impose a change in the standard to all other
implementations that maybe out there now, just because one arch got it
wrong *and* there is a doable path out of that mess.
I wouldn't even know how to argue a defect report for that.
> The other direction, passing uninitialized data from the kernel to
> userspace, would be dangerous. But it doesn't happen as long as the
> userspace padding is positioned (in an endian-dependent manner) where
> the high bits of the kernel type would lie. It could happen if you
> used a separate conversion wrapper that ony wrote 32 bits, but if you
> wanted to take that approach you'd just need the wrapper to also write
> the padding field manually.
>
> > In the kernel headers, the current plan is to provide interfaces taking
> > structures
> >
> > typedef long long __kernel_time64_t;
> > struct __kernel_timespec64_t {
> > __kernel_time64_t tv_sec;
> > long long tv_nsec;
> > };
> >
> > at least for ioctls, to avoid the ambiguity with libc headers specifying
> > something else.
>
> This seems hideous from an application standpoint. Application
> programmers don't want to know, and shouldn't need to know, these
> silly implementation details that make no sense except as historical
> baggage. They should just be able to use "struct timespec" everywhere
> and have it work.
Exactly, this is what standards are for.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
