[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #4598] filesystemRepresentation on Win32 is DANGEROUS as impl
Re: [patch #4598] filesystemRepresentation on Win32 is DANGEROUS as implemented
Sun, 06 Nov 2005 10:15:59 +0800
Mozilla Thunderbird 1.0.6 (Windows/20050716)
Jeremy Bettis wrote:
Follow-up Comment #1, patch #4598 (project gnustep):
Ok, so how about replacing every occurance of unicodeFileSystemRepresentation
with (unichar*)[path cStringUsingEncoding: NSUnicodeStringEncoding]
which is what unicodeFileSystemRepresentation actually does internally.
Although fine for the moment, I don't think it's the best solution ultimately.
We can clean up the code so unicode on Win32 is the norm and used everywhere.
I'd much rather see a transition to using Win32 API calls for this handling
rather than routing it through the *nix/C compatibility layer. We're a little
bit of the way there but there is plenty still to do.
I would be fine with that approach also. My non-negotiable is that
filesystemRep returns char*.
Absolutely. The idea has always been:
ret = nix_system_call( [pathString fileSystemRepresentation] );
and breakage of this shouldn't be accepted.
I think the goal, though, should be:
- for application code to rely entirely on NSString to hold the path and other
NS API calls to operate on those files. Avoid the need to call down
- for core code to better encapsulate Win32 and use less *nix approaches. We
gain in both performance and behaviour.