Re: Errata corrige: Memory exhaustion: different Lua functions, error messages and exit codes

[Viacheslav Usov <via.usov@...>]

On Thu, May 21, 2020 at 10:50 PM Massimo Sala <massimo.sala.71@gmail.com> wrote:

> A direct pointer comparison can fail. This test cannot fail:
>
>> if (ret != 0 && strcmp(ptr, MEMERRMSG) == 0)
>>     ret = LUA_ERRMEM;
>
>
> Do you agree on "better safe than sorry" ?

As I said previously, Lua (5.3) uses MEMERRMSG exactly once, to
initialize g->memerrmsg, after which only the latter pointer is used.
So it is not dependent on the compiler [sic] options that govern the
handling of duplicate strings.

Cheers,
V.

>
>
> 2) The main picture
>
> Different Lua functions exit with different error messages and exit codes, even in case of the same error condition.
>
> Examples in case of insufficient memory:
>
>> lstring.c: LUA_YIELD : "not enough memory"
>> lauxlib.c: LUA_ERRRUN : "test.lua:10: not enough memory for buffer allocation"
>> lstrlib.c: LUA_ERRRUN : "test.lua:11: resulting string too large"
>
>
> Lua defines a specific error code: LUA_ERRMEM.
> When realloc failes, why do some Lua functions return LUA_ERRMEM other ones return LUA_YIELD or LUA_ERRRUN ?
> I am talking about basic functions: lua_newstate, luaL_openlibs, luaL_requiref, luaL_loadfilex, lua_pcall.
>
> I use a lot of libraries, I am used to get the same error code in case of the same cause.
> Example: Iit is quite problematic to test for insufficient memory conditions, with all these combinations of return codes.
>
> Does anybody recognize this inconsistent behavour of the APIs?
> Am I the only one annoyed about it?
>
> Thanks for your attention,
> Massimo
>
>
> On Thu, 21 May 2020 at 21:51, Coda Highland <chighland@gmail.com> wrote:
>>
>> On Thu, May 21, 2020 at 1:34 PM Viacheslav Usov <via.usov@gmail.com> wrote:
>>>
>>> On Thu, May 21, 2020 at 6:51 PM Coda Highland <chighland@gmail.com> wrote:
>>>
>>> > Are you aware of a linker that doesn't unify string literals?
>>>
>>> Well, the boundary between the compiler and the linker is blurry these
>>> days, but I'd say you would need to ask the compiler for that. In some
>>> (debug?) builds this may be off by default.
>>>
>>> Lua itself assumes nothing about that, keeping that string pointer in
>>> the global state and using only the pointer after it was initialized.
>>> I did not understand what Massimo was trying to achieve.
>>>
>>> Cheers,
>>> V.
>>
>>
>> It's not stored in the global state. It's a #defined constant, unless the earlier post was wrong about that. It would depend on the linker identifying that the different constant data symbols are in fact the same and can be updated to the same pointer.
>>
>> If this can't be relied upon, then Massimo is completely correct that the comparison is wrong.
>>
>> /s/ Adam