Re: Bugs and questions

[Luiz Henrique de Figueiredo <lhf@...>]

>From: "mvezzosi@libero."<mvezzosi@libero.it>

>I compile Lua for a 16 bit environment and my compiler 
>consider the Int C type composed by 16 bits.

We tried to avoid any potential problems for 16-bit systems, but we do not
have a real 16 bit environment to test it. So, thanks for the comments.
You'll see what can be done.

>1) In lmem.h the macros
>#define luaM_newvector(n,t)      ((t *)luaM_malloc((n)*sizeof(t)))
>#define luaM_reallocvector(v,n,t)     ((v)=(t *)luaM_realloc(v,(n)
>*sizeof(t)))
>can pass a wrong size value to luaM_realloc() if Int is composed by 16 
>bits and "n" is big enough.

luaM_malloc is a macro that calls luaM_realloc, whose declaration is

	void *luaM_realloc (void *block, unsigned long size);

So, there should be no problems, unless sizeof returns int.

>IMO the macros should contains a cast to unsigned long:

This makes sense, but malloc is defined as

	void *malloc(size_t size);

and so if sizeof returns int then casting to unsigned long wouldn't help.
Perhaps a cast to size_t works.
Could you try this on your example?

>  - lbuiltin.c->luaB_predefine() with the macro DEBUG defined:
>luaB_opentests() gives "unresolved external" (there is also the 
>function's prototype at line 44).

luaB_opentests is only used here, for testing.
But we are considering distributing it too.

>IIRC, this warning was already posted but related to luac and without DEBUG.

I don't recall this.

>3) In interactive mode, after entering the line (for examples)
>   a, b = read("*n", "*n")
>   Lua displays 2 prompts ("> >").

This is ok. The problem is that the lua interpreter is reading from stdin too,
and so is "read", of course. So, they are competing for the same buffer and
messing things.  But I don't know why it displays 2 prompts.

>1) Sometimes I need to return the elements of a table as single 
>variables. For examples:
>function read(...)
>        dosomething()
>        local retlist = call(%read, arg, "p")
>        dosomethingelse()
>        return tunpack(retlist)  [see forward for tunpack()]
>end
>a, b = read("*n", "*n")

"read" already does that. I guess your point it the dosomething() and
dosomethingelse(). I hope that dosomethingelse() uses retlist :-)

>Is there a better way to do this ? (I would like to avoid the 
>recursion's overhead and to destroy the table)

Not that I know. :-(

>3) Is it possible to avoid the assignment of some arguments in the "="
>operator ?

No. The way we usually do this in our own programs is by using "_":

local _,a,_,b = dosomething()

Usually, dosomething is strfind :-)

--lhf