develooper Front page | perl.perl5.porters | Postings from March 2001

USING_WIDE(), and perl -C etc.

Thread Next
March 5, 2001 08:39
USING_WIDE(), and perl -C etc.
Message ID:

I am in the process of looking at pp_sys.c to see what other calls
need to automatically downgrade like Camel-III says gethostbyaddr() does.

I was looking to see how Win32 handles its "wide" variant to make sure I did
not break it.  I didn't, but I think it _is_ broken ...

It is subject to the normal go-straight-for-the-guts approach, without 
taking into account that guts can be in two possible representations.
It blindly calls 

#define A2WHELPER_LEN(lpa, alen, lpw, nBytes)\
    (lpw[0] = 0, MultiByteToWideChar((IN_BYTE) ? CP_ACP : CP_UTF8, 0, \
				    lpa, alen, lpw, (nBytes/sizeof(WCHAR))))

With out ensuring that "lpa" is indeed UTF-8 encoded.

Of course by time win32/win32.[ch] see it you only have a char *,
so the problem is back at pp_sys.c/doio.c etc. 

My current idea is that pp.h should define


rather than just POPpx.

POPpsysx would have logic like:

return (IN_BYTE || !PL_widesyscalls) ? SvPVbyte(sv) : SvPVutf8(sv);

Where SvPVbyte does a downgrade-if-required 
  and SvPVutf8 does an upgrade-if-required

That way the low-level C would know what it was getting.
(That is also close to what Linux/UNIX would want if widesycalls meant 
filenames etc. were in UTF-8.)

A possible snag with that is that it does not include the 

  PerlEnv_os_id() == VER_PLATFORM_WIN32_NT 

term that is in USING_WIDE()
The simple fix to that is to stop PL_widesyscalls getting set 
if the Win32 variant cannot do wide syscalls...

Nick Ing-Simmons

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About