What's the semantics of the indices in the mapping "fc" in the master? dirnodes insert themselves twice in this mapping, once with ".pmod" on the end and one without, meaning that rev_fc will randomly contain one of these names. However, findmodule() will only accept the version without ".pmod" if the module is not already in fc. This breaks dumping of the Charset module. It seems to me that dirnodes should only insert the name without ".pmod" into fc, is there some special reason why it is inserted twice now?
Some digging reveals that that is very old code, probably from the dark confused ages.
I think it'd be more natural if fc would contain the straight paths, without any suffix chopping. That way there are only two things: Either a name in the module namespace or a path in the filesystem (or possibly a relocated path if PIKE_MODULE_RELOC is enabled). No tricky intermediate varietes. Am I reasoning too simplistic? Is there a reason to chop off the suffixes in this case?
Some digging reveals that that is very old code, probably from the dark confused ages.
Sounds likely.
From ulpc/lib/master.lpc:
| object cast_to_object(string oname) | { | object ret; | | if(oname[0]=='/') | oname=combine_path(getcwd(),oname); | | if(oname[sizeof(oname)-3..sizeof(oname)]==".lpc") | oname=oname[0..sizeof(oname)-4]; | | if(ret=objects[oname]) return ret; | | return objects[oname]=clone(cast_to_program(oname)); | }
I think it'd be more natural if fc would contain the straight paths, without any suffix chopping. That way there are only two things: Either a name in the module namespace or a path in the filesystem (or possibly a relocated path if PIKE_MODULE_RELOC is enabled). No tricky intermediate varietes. Am I reasoning too simplistic? Is there a reason to chop off the suffixes in this case?
I guess it has to do with the relaxed filename handling in handle_include() et al, that accept filenames without extension.
Ok, but afaics fc is not used from handle_anything (at least not anymore). It's only used from the default codec via the findmodule function. So I don't think there should be any problem making findmodule more strict.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum