lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi Massimo.

On Wed, May 13, 2020 at 10:45 PM Massimo Sala <massimo.sala.71@gmail.com> wrote:
> I admit I picked up a corner case.

No problem. I have many concerns in some of my Lua uses with memory
occupation, it just surprised me a file name could be a problem there.

> 1) In general, I dislike APIs returning unnecessary data.
> If I call a function
>      loadfile(const char * szFilename, ...)
> it is obvious file errors are referred to szFilename !

It is. But What I was saying is the lauxlib is mainly optional. IIRC
you need it to build the lua executable, but you can work fine without
it, the manual states it and the sources reveal thay are mainly
convenience wrappers, and one of their main uses is the messages it
produces are normally log-file ready ( I use it mainly for this ).

> 2) Estimation of maximum size of error messages
> If I use a library and functions can return error messages, I prefer they are constant string.
> This way I know a priori the maximum size of the messages and there aren't nasty surprises regarding head and stack occupation.

Yeah, that's good although for this case I prefer error codes to test them.

> I know I am finicky, but these concerns make it easier to write maintainable software, without side effects.
> You really don't know which filenames will appear as input of your functions, when other users utilize them.

That's true, but working on a garbage collected scripting language you
can easily have an OOM if you are under such memory pressure that a
filename pushes you. I mean, the function seems to use 2*BUFSIZ
memory, one of them stack allocated, this means it is not dessigned
for memory constrictions. And also, GC is not dessigned for really
constrained memory environments. I have not seen Lua tests, but all
the papers I read, mainly for Java, show it works best when it uses
two/three times the working set size ( discounting the classic
long-term big allocations present in many systems, just for the
dynamic part ). I, personally, would choose a tool with other type of
memory management, like ref counting which is slower and a tad more
complex but leaves you with only the memory fragmentation issue, which
can normally be proven to be irrelevant.

> As people say in south Italy "ogni scarrafone è bello a mamma sua" "até o mais feio é lindo para sua mãe".

Scarrafone. Haven't heard that one. I know just the person who I'm
gonna throw it to at first chance :) .

Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org