[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Re: [ANN] LuaJIT x64 port sponsorship program
- From: Mike Pall <mikelu-0912@...>
- Date: Wed, 9 Dec 2009 17:33:07 +0100
Jerome Vuarand wrote:
> > You can pass it any pointer value that is legal on x64 in
> > user-mode under the currently supported 48 bit memory model. In
> > practice this means it's accepted by lua_pushlightuserdata() if
> > the highest 16 bits are zero (user-mode pointers can only point to
> > addresses 0 .. 2^47-1).
> Does that mean that C modules that use light userdata to store size_t
> integers (for example for bitfields) will have the upper 16bits
> clamped ? For the moment I'm mostly concerned by the win32 API, which
> uses the UINT_PTR type quite often. However in the partial bindings I
> have so far all enum and bitfield types are 32bits (mostly DWORD).
What you're intending to do is not covered by any C standard.
Yes, you may cast a pointer into an intptr_t and get it back later
(*2). But the inverse is generally not allowed (*1). You can't
cast arbitrary bit patterns to a pointer and assume this doesn't
cause an exception or that you get them back unmodified later.
You'll get away with it on most platforms, but your code would
rely on undefined behavior.
The signature of lua_pushlightuserdata(lua_State *L, void *p)
makes it quite clear that you need to pass a pointer. Arbitrary
bit patterns that happen to fit into a pointer-sized object do not
qualify. It must be a valid pointer per the memory model (see above).
[AFAIK the WIN32 API only relies on ptr->UINT_PTR->ptr, but not
You'll be able to use 64 bit integers and other native data types
with the planned FFI/struct extension. 64 bit data will be boxed,
unless stored in native arrays. The JIT compiler can be extended
to avoid the boxing/unboxing overhead in many cases.
The FFI/struct extension is probably the next bigger project after
the x64 port.
(*1) C99 126.96.36.199 Pointers
- (5) An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined, might
not be correctly aligned, might not point to an entity of the
referenced type, and might be a trap representation.
- (6) Any pointer type may be converted to an integer type. Except
as previously specified, the result is implementation-defined.
(*2) C99 188.8.131.52 Integer types capable of holding object pointers
- The following type designates a signed integer type with the
property that any valid pointer to void can be converted to
this type, then converted back to pointer to void, and the
result will compare equal to the original pointer:
[Ditto for uintptr_t.]
These types are optional. [But most platforms have them.]