Re: functions, errors: is it good to report back the filename?

[Massimo Sala <massimo.sala.71@...>]

Hi Francisco

Many thanks for your detailed explanation.

I agree, my use case is too specific.

I solved pre-allocating a buffer for error strings before calling any lua function.

Calculation the buffer size, I take care of the maximum length of filenames.

When I get an error from lauxlib, I strncpy the error string to the preallocated buffer.

M

On Tue, 12 May 2020 at 16:52, Francisco Olarte <folarte@peoplecall.com> wrote:

Massimo:

On Mon, May 11, 2020 at 11:28 PM Massimo Sala <massimo.sala.71@gmail.com> wrote:
> luaL_loadfilex calls errfile that buld the error message including the filename:
...
> luaL_loadfilex is an example; my question is general, also for other functions.
...
> The filename could be very long.
> In my specific environment - embedded with low memory - it is better error messages have a predictable max size.
> This isn't possible if they depends on a variable value.
> If the caller of the API wants a verbose message, it knows the filename and so can add it.
> If the caller of the API has constraints... it is a bit difficult to remove the filename from the error messages...
> Please let me see your thoughts about this.

IMHO by using the aux library you are trading memory ( among other
things, the library needs to be included ) for convenience and easier
programming. Your particular case seems to be like the prototypical
example of when not to use it for certain things. You can easily
reimplement it with error handling more suitable for your environment,
and possibly less memory consumption if you are worried, by "creative
imitation" from lauxlib.c.

If your environment is so memory constrained you are worried about a
duplication of a filename ( which, in a memory constrained
environment, shouldn't be that long ), you are also going to worry
about the BUFSIZ allocated for LoadF in that function, along with ,
unless your stdlib is very tuned, extra buffer allocation needed for a
FILE. If you are that constrained, you can work a lua_load reader with
calls to open/read/close and really tiny buffers, custom fixed size
errors, and even get rid of optional boms and initial comments, those
kind of enviroments do not normally need all this things.

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

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