Page MenuHomeFreeBSD

flua: lposix: add more useful functions for general purpose scripts
ClosedPublic

Authored by kevans on Mar 15 2023, 5:31 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 30, 7:42 AM
Unknown Object (File)
Oct 11 2024, 7:29 AM
Unknown Object (File)
Oct 11 2024, 7:27 AM
Unknown Object (File)
Oct 11 2024, 7:13 AM
Unknown Object (File)
Oct 3 2024, 5:37 AM
Unknown Object (File)
Oct 1 2024, 6:00 AM
Unknown Object (File)
Oct 1 2024, 2:13 AM
Unknown Object (File)
Sep 30 2024, 5:37 PM

Details

Summary

unistd:

  • _exit
  • close
  • fork
  • getpid
  • pipe
  • read
  • write

libgen:

  • basename, dirname

stdlib:

  • realpath

These are sufficient for a number of real world scenarios. In our first
application of them, we use the libgen+stdlib additions to grab the
script dir based on argv[0]. The unistd assortment is then used to
outsource a bunch of work to forks and report back to the main process.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Use allocf, matches lua's internal naming

I don't understand why you need lposix_alloc and lposix_free at all vs direct call to free and malloc?

libexec/flua/modules/lposix.c
1–2

Why this extra line?

132

Why changing style?

libexec/flua/modules/lposix.c
1–2

care to add SPDX headers while here?

In D39083#898199, @bapt wrote:

I don't understand why you need lposix_alloc and lposix_free at all vs direct call to free and malloc?

Better form for a lua lib, though this one shouldn't see the light of day since it's a reimplementation of lposix so I could just simplify it.

overall looks good

libexec/flua/modules/lposix.c
83

is it ok to call this if inpath == NULL?

348

is it typical to use n for this? unless it's std lua convention maybe something more descriptive like narg?

kevans marked 5 inline comments as done.

Address comments; fix return consistency; a couple of missed return (3) and
one return (1) that should've been 3

libexec/flua/modules/lposix.c
83

D'oh, that should have had a return (3) otherwise the return value ends up being a bit nonsensical (and we leak two stack entries, iirc).

This revision is now accepted and ready to land.Sep 1 2023, 5:03 PM

So this looks generally good, modulo some error messages about having args having the function name and some not.

libexec/flua/modules/lposix.c
1–2

... and remove the boilerplate?

144

Close vs pclose in error message.

173

No name here? But close had one. Here and elsewhere

483

Why pclose?

kevans added inline comments.
libexec/flua/modules/lposix.c
483

lua_close() conflicts with the API function that releases a lua_State

This revision was automatically updated to reflect the committed changes.
kevans marked an inline comment as done.