in reply to Re^2: -e " " returns true
in thread -e " " returns true

On this occasion, it appears that the problem is internal to Perl--with caveats.

The problem occurs in these two lines from win32\win32.c (line numbers are approximate (5.8.4) because I've added debug code):

1222: pwbuffer = PerlDir_mapW(wbuffer); ... 1228: path = PerlDir_mapA(path);

Prior to these to lines the vars; path / wbuffer contain the bad paths being tested ( ' ', ' . . ' etc. ), but after they contain the fully expanded current working directory. They should not.

So, the problem is in the routines PerlDir_mapW() / PerlDir_mapA(). The stat being returned for non-existant directory paths is that of the current working directory.

But there, my trail grows cold. These functions are not functions, but #defines.

One path through the #defines in iperlsys.h has these resolved to:

#ifdef WIN32 #define PerlDir_mapA(dir) dir #define PerlDir_mapW(dir) dir #endif

But that can't be right because then they would be unchanged and the problem wouldn't occur.

The other branch of the #if defined(PERL_IMPLICIT_SYS) in iperlsys.h resolves them to entries in a vtable.

#ifdef WIN32 #define PerlDir_mapA(dir) \ (*PL_Dir->pMapPathA)(PL_Dir, (dir)) #define PerlDir_mapW(dir) \ (*PL_Dir->pMapPathW)(PL_Dir, (dir)) #endif

but search high'n'low, I cannot find out where these vtable entries are filled in?

It appears to be related to PL_curinterp and embedvar.h, but I tracked it back through about 6 levels of indirection before getting completely lost. It will take someone much cleverer than me to resolve this further.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon