Re: newbie: local buf = ffi.new("char[?]", "HELLO WORLD") fails PROBABLY SOLVED

  • From: Patrick Masotta <masottaus@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Thu, 21 Jun 2012 14:41:05 -0700 (PDT)

I think the main reason for thinking of a patch is because
ffi.new quietly initializes a VLA of "zero" bytes; that's a bug.
From that point why not using 0 as an easy way to initialize implicit length C 
strings ?
Anyway I do not want to convinvce to anyone about this; the application I'm 
coding will use this patch and I'm very happy with it, I'm focused on LUA-C 
integration then I do not need embedded 0s when I handle C strings plus I love 
the symetry and beauty the patch gives to C strings declarations.

best


--- On Thu, 6/21/12, Adam Strzelecki <ono@xxxxxxx> wrote:

> From: Adam Strzelecki <ono@xxxxxxx>
> Subject: Re: newbie: local buf = ffi.new("char[?]", "HELLO WORLD") fails 
> PROBABLY SOLVED
> To: luajit@xxxxxxxxxxxxx
> Date: Thursday, June 21, 2012, 2:12 PM
> > 1) why do you think it is a
> _much_ better solution than patching ffi.new().?
> 
> IMHO only reasonable justification to patch this is that
> either it is too slow, it is a bug or something can be
> achieved with current API. Therefore I think your arguments
> miss all these points.
> 
> But indeed I agree there's something wrong with ffi.new
> which allows to "allocate" zero sized array. Shouldn't it
> raise an error ffi.new("char[?]", 0, ...) ?
> 
> As for possible extension in case for VLA/VLS ct - if 2nd
> argument isn't number nelem could be determined from its
> size, why not? So we could do:
> 
> local buf = ffi.new('char[?]', 'Hello world!')
> 
> Or:
> local cstring = ffi.typeof('char[?]')
> local buf = cstring('Hello world!')
> 
> So far FFI API isn't frozen, moreover such change will keep
> backwards compatibility, because anyway before 2nd argument
> had to be number in case of VLA/VLS.
> 
> Cheers,
> -- 
> Adam Strzelecki | nanoant.com | twitter.com/nanoant
> 
> 
> 

Other related posts: