Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: Userspace compiler support of "long long" | Date | Thu, 28 Jun 2007 08:18:50 -0400 |
| |
On Jun 28, 2007, at 08:08:03, Jakub Jelinek wrote: > On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: >> Oh, ok, that makes it even easier to say this with certainty: >> Changing the other 64-bit archs to use "long long" for their 64- >> bit numbers will not cause additional warnings. I'm also almost >> certain there are no architectures which use "long long" for 128- >> bit integers. (Moreover, I can't find hardly anything which does >> 128-bit integers at all). > > unsigned long and unsigned long long have the same size, precision > and alignment on all LP64 arches, that's true. But they have > different ranks and more importantly they mangle differently in C+ > +. So, whether some user exposed type uses unsigned long or > unsigned long long is part of the ABI, whether that's size_t, > uintptr_t, uint64_t, u_int64_t or any other type, you can't change > it without breaking the ABI.
That sounds *extraordinarily* broken. Hopefully this would *not* affect the type of a function which is passed a C "struct" containing the "long long", right?
Hmm, I guess the question is: Do we support people directly passing __u64 to C++ functions in userspace? I could understand, perhaps, passing around structures defined in the kernel headers, but certainly not the kernel-internal types. The only reason we even export those is so we can have a private set of bit-size-defined types with which to define kernel ABI structures.
Cheers, Kyle Moffett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |