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

  • From: Patrick Masotta <masottaus@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Fri, 22 Jun 2012 00:04:28 -0700 (PDT)

1) One thing is "No Hand-holding!" another thing is inconsistency:
local var_01 = ffi.new("char[?]",3, "Help”);    --gives you “He”
local var_01 = ffi.new("char[?]",0, "Help”);    --gives you “Help” and memory 
corruption

Then; is anyone out there thinking this does not need a bug fix in LJ code???


2) I’m just “recycling” what I consider an error condition (size=0)
to something that can be useful when dealing with “C” friendly implicit size 
strings, (something I do pretty often) That’s it.

> If a patch were to be made (and I'm not advocating that,...
Do you think LJ needs a bug fix on sz=0    [YES][NO] ?

> then I would much rather see a more generic version that
> supports any data buffer being passed, 
The viability of this depends on the ability of getting the size of such
generic data buffer being passed. Doing it on a C friendly string is pretty 
easy,
Doing it over a generic LUA string could also be possible as you guys said
the initialization string is converted into a LUA string, then its size
should be also available at ffi.new

>rather than a specific hack for strings.
Don’t call what I did a “hack”; it is a bug fix that makes life easier when 
dealing with C strings…

>Hence my previous comment about using the Lua string length rather than 
>strlen().
I understand your point but that really gives an ugly hack…

>I'd also expect (without looking at the internals of LuaJIT to know if it has 
>access to the Lua
> object) this to be somewhat faster - Lua already knows the length.
I’m not very familiar with LJ code, I couldn’t find the initialization LUA 
string
I agree with this, if ffi.new can easily get the initialization LUA string  
size then
It should be used instead of strlen(),  that would make a broader use of my 
patch extending it to LUA strings…


--- On Thu, 6/21/12, Claire Lewis <claire_lewis@xxxxxxxxxxx> wrote:

> You're making two assumptions here;  that a function
> being passed a char * is a pure ASCII string, and that Lua
> string types contain ASCII strings. Neither of these are
> correct.  There are plenty of cases where functions
> take char * that are arbitrary buffers in various APIs, and
> Lua strings certainly can (and do) contain binary data.
> 
> If a patch were to be made (and I'm not advocating that, but
> it makes little difference to me if Mike decides to do so),
> then I would much rather see a more generic version that
> supports any data buffer being passed, rather than a
> specific hack for strings.  Hence my previous comment
> about using the Lua string length rather than
> strlen().  I'd also expect (without looking at the
> internals of LuaJIT to know if it has access to the Lua
> object) this to be somewhat faster - Lua already knows the
> length.
> 
> - Claire.
> 
> 
>

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 06-2012