Re: data initialisation bug?
- From: Mike Pall <mike-1205@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 16 May 2012 12:36:17 +0200
Arran Cudbard-Bell wrote:
> The initializer rules state:
> Byte arrays may also be initialized with a Lua string. This
> copies the whole string plus a terminating zero-byte. The copy
> stops early only if the array has a known, fixed size.
>
> ffi = require('ffi')
>
> local str = ffi.new('char [?]', 4, 'string')
A VLA is a 'variable-length array' and thus does not have a
'known, fixed size'. This is restated a bit further down in the
section on table initializers, too.
Initializers only get the target type, which doesn't include the
size for a VLA. Only the instance of a VLA has a known size, but
that's not accessible to the initializer in general (you may be
initializing the array part of a VLS or an array nested in a
struct etc.).
[
BTW, a heads up: it may get significantly more expensive to do a
sizeof(VLA) with the move to the new GC in LuaJIT 2.1. This is
another reason why I'm not introducing a '#' operator as it would
need to compute sizeof(VLA)/sizeof(VLA_element).
The reason for this is the new GC doesn't need the size of an
object to be stored in the object itself. So it would be a waste
of space to do that. The size of an object can still be derived
from the segregated metadata bits. But that's a rather expensive
operation. And nothing else in the VM ever needs to do that.
]
--Mike
Other related posts:
