So the solution is:
local ffi = require"ffi"
local cType = ffi.typeof("float[?][2]")
math.randomseed(1)
for i = 1, 10 do
local t = {}
local counter = math.random(1000)
for l = 1, counter do
t[l] = {l, 0}
end
local z = cType(counter, t)
collectgarbage()
local sum = 0
for l = 0, counter - 1 do
sum = z[l][1] + z[l][0] + sum
end
end
or:
local ffi = require"ffi"
local cType = ffi.typeof("float[?][2]")
local t = {}
math.randomseed(1)
for i = 1, 10 do
local counter = math.random(1000)
print(counter)
for l = 1, counter do
t[l] = {l, 0}
end
assert(#t <= counter, "initializer overflows allocation")
local z = cType(counter, t)
collectgarbage()
local sum = 0
for l = 0, counter - 1 do
sum = z[l][1] + z[l][0] + sum
end
end
On Tue, Nov 15, 2016 at 12:47 PM, Javier Guerra Giraldez <javier@xxxxxxxxxxx
wrote:
On 15 November 2016 at 03:16, Andrea Guerra
<andrea.guerra.mail@xxxxxxxxx> wrote:
I initialize the VLA (z) with a longer table
(t) than the number of elements (counter), should this rise an error
(excess initializer)?
this is definitely the issue. removing the collectgarbage() line
makes it pass for most cases, but tweaking the other values makes it
still happen.
for example:
local ffi = require"ffi"
local cType = ffi.typeof("float[?]")
local t = {}
for i = 1, 10 do
local counter = 50*(10-i)
for l = 1, counter do
t[l] = l
end
local z = cType(counter, t)
end
still fails (LuaJIT 2.1.0-alpha JIT: ON SSE2 SSE3 SSE4.1 fold cse dce
fwd dse narrow loop abc sink fuse), on Linux (kernel 4.4.0)
and, of course, adding "t[counter+1] = nil" just after the inner loop
makes it work in every case.
Just because the initializer doesn't raise an error immediately, it
doesn't mean everything is OK. Many memory corruption bugs only
surface long, after, when some other part of the code is traversing
inner structures (like on garbage collection).
cheers,
--
Javier