Re: changes in 'require'

[Mike Pall <mikelu-0507@...>]

Hi,

Roberto Ierusalimschy wrote:
> > * Windows module search path issues:
> 
> Instead of a patch, I would appreciate some clarification :) Should we
> use NULL as the hModule argument?

Definitely. We want to get the name of the executable.

An alternative would be a handle to the Lua core DLL, but it's harder
to retrieve. I can see an argument for the modules being relative to
the executable (you could have more than one standalone) instead of
all of them being relative to the core DLL (which may be shared).

> Should we use "PathRemoveFileSpec" to strip the executable name?

Sure. MS recommends it and I see no advantage in using strrchr()
plus some additional logic.

> Is there a "reasonable" maximum size for the file name?

MAX_PATH is 260 on WIN32. Seems short enough for a stack-allocated array.

> > I think a convenient solution would be to strip an underscore prefix
> > from the module name before generating the init function name.
> 
> An alternative would be to use only the sub-module name, without the
> parents. Instead of renaming "foo.so" to "_foo.so", rename it to
> "p/foo.so". It seems to be a good idea to hide a private module outside
> the main directory, and we simplify the generation of the funcname (no
> more LUA_OFSEP). (On the other hand, that could create name conflicts
> for homonymous sub-modules from different packages...)

In fact identically named symbols from different shared libraries
should not conflict. At least not the way Lua loads them:

Windows: There is no global symbol namespace. All symbols are
         tied to the handle of the DLL they reside in.
POSIX:   dlopen() is called without RTLD_GLOBAL.
OSX:     NSLinkModule() is called with NSLINKMODULE_OPTION_PRIVATE.

So, I do not see a problem with this change.

Bye,
     Mike