Add fnmatch() to libexec/flua

[se]

Summary

It is not possible to fully emulate the fnmatch() function LUA regular expressions.
I've been using a patched version of FLUA for some time, since I need it to match package names against COBFLICTS patterns in port Makefiles.
It is generally useful to match file names read from files against glob patterns, without these files necessarily existing on a file system.
Adding this function increases the binary size of flua by less than 1 KB on amd64.

Test Plan

Apply the patch and rebuild flua.
Test that fnmatch can be used:

local fnmatch = require ("posix.fnmatch")
print ("no match result=", fnmatch.FNM_NOMATCH) -- expect 1
print (fnmatch.fnmatch("*.so.*", "bash")) -- expect 1
print (fnmatch.fnmatch("*.so.*", "libc.so.7")) -- expect 0

[markj]

Looks ok to me aside from a question.

libexec/flua/modules/lposix.c

179

Should flags be a lua_Integer? Otherwise we are silently truncating here.

[se]

libexec/flua/modules/lposix.c

179

The types of the local variables are copied from the lua-posix module, where flags is also "int".
The flags parameter of the C function is of type "int", therefore no wider integer could be passed into the fnmatch function, anyway.

[markj]

libexec/flua/modules/lposix.c

179

Right, but in lua one can pass an integer larger than INT_MAX, and it'll get silently truncated here. At least, I believe that can happen, or am I missing something?

[se]

libexec/flua/modules/lposix.c

179

Correct, but flags is only defined in the range 0..7, and the C function only ever accesses the lowest 3 bits of the value. All higher bits are ignored, truncation will not cause any issues, AFAIU.
If we assign the third parameter to a lua_Integer, it would still be truncated to an int, since that is what the C function expects. We could add a range check to reject values > 7, but that's neither done by the C function nor tfnmatch in the POSIX LUA module.
The fnmatch function returns just 0 (match) or 1 (no match). No other value is expected, and while we could return "no match" for flags > 7, I do not think that is reasonable, since the C function considers the flags parameter a bitset with only the 3 lower bits carrying useful information and the rest being "don't care" values.

Please let me know whether I misunderstand the effect of truncation - I'll hold back the commit until there is agreement about this being an issue or not ...