Front page | perl.perl5.porters |
Postings from March 2013
On 03/25/2013 09:35 AM, yves orton via RT wrote: > On 25 March 2013 15:28, Leon Timmermans <fawaka@gmail.com> wrote: >> On Mon, Mar 25, 2013 at 3:14 PM, demerphq <demerphq@gmail.com> wrote: >>> Reini, on Win32 filenames are stored internally as UTF-16. What affect >>> does your patch proposal have on opening files with widecharacters in >>> them? (Widecharacters as you know could easily contain nuls). >> >> Perl uses legacy interfaces on Windows (that is, it accesses the >> filesystem using 8-bit interfaces, the encoding is system-defined but >> tends to be latin-1, which saves our ass most of the time). >> >> I'd consider this our number one Windows bug (because it screws up >> badly when trying to open files with Unicode in their names), but >> fixing this will be non-trivial, and few people have the appropriate >> Windows knowledge anyway. > > Im just worried that Reinis null surpression might break something > there. Sounds like you think we needn't worry on that point, as such, > I wont. :-) I'll test it. win32ce for sure uses the wide api, and seems to use wide perl strings, which would break then, right. For win32 plain I guess It's some global settings which controls if the W or A version is used, and I see no translation from perl utf8 strings to the wide strings in win32/win32io, They are used asis. And I'm not sure if -C allows using wide chars (seems to set only utf-8), or if wide locales are even valid. I only know about nul-safe encodings, and -C was used to set wide until 5.8.1 on windows. The -C wide API was disabled since then. -- Reini Working towards a true Modern Perl. Slim, functional, unbloated, compile-time optimizableThread Previous | Thread Next