patchGNUstep - Patches: patch #4598, filesystemRepresentation on Win32...

Group
 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #4598: filesystemRepresentation on Win32 is DANGEROUS as implemented

Submitter:  Jeremy Bettis <jeremybettis>
Submitted:  Fri 04 Nov 2005 09:01:20 PM UTC
   
 
Category:  Foundation Priority:  9 - Immediate
Status:  Wont Do Privacy:  Public
Assigned to:  None Open/Closed:  Closed

Sun 06 Nov 2005 06:27:06 AM UTC, comment #2: 

Sorry to be slow responding to this ... but I spent saturday and part of friday with my machine running windows (as part of the ongoing effort to get mingw support to a similar state as unix) ... so didn't have my GNUmail client running to pick up my emails.

This patch can't be applied because a few bits of it are already in place, other bits are inappropriate, but also it reintroduces complexities we are trying to get rid of.

Responding to your original points ...

> filesystemRepresentation is declared as returning char* when it actually returns unichar*


I already changed that to be dependent on the _MINGW32_ preprocessor constant, once I'd rationalised the system to use a single consistent constant throughout.  In any case, the behavior of the method is clearly documented.
 

> Even gnustep-base itself has uses of filesystemRepresentation that are not expecting unichars.


That shouldn't be the case ... but porting to mingw32 is a work in progress...  While there shouldn't be any non-unicode mingw32 calls in use, we do need to keep checking and replacing them where we find them (I'm intending to fix the timezone stuff in the registrly, though since all the relevant registry keys are ascii, that's more for consistency than necessity).  I believe there are also places where inefficient posix compatibility functions are used and it would be better to use native win32 api.

> Unicode is NOT the native filesystem encoding for the Win32 API. Win32 actually has 2 "native" encodings.


I think you mean it has two APIs (it certainly supports more than two encodings) and are referring to the variants of the functions in the win32 API for 8bit and 16bit characters. However, the existence of two variants of functions is clearly a transitional backward compatibility issue, since modern windows systems are built to the new 16bit api and implement the old api as wrappers round it (and windows CE drops the old 8bit api, only having the new one).
The base library needs to stick to the KISS principle and support   one API ... we should not be adding methods in order to support two windows APIs, when one of them is obsolete, and when there are mechanisms in both windows and GNUstep for doing character conversion for the case where a windows programmer wants to use the old win32 functions rather than the new ones.

Richard Frith-Macdonald <CaS>
Group Member
Sat 05 Nov 2005 04:31:49 PM UTC, comment #1: 

Ok, so how about replacing every occurance of unicodeFileSystemRepresentation with (unichar*)[path cStringUsingEncoding: NSUnicodeStringEncoding]
which is what unicodeFileSystemRepresentation actually does internally.

I would be fine with that approach also.  My non-negotiable is that filesystemRep returns char*.

Jeremy Bettis <jeremybettis>
Fri 04 Nov 2005 09:01:20 PM UTC, original submission:  

) filesystemRepresentation is declared as returning char when it actually returns unichar*
*) Even gnustep-base itself has uses of filesystemRepresentation that are not expecting unichars.
*) Unicode is NOT the native filesystem encoding for the Win32 API.  Win32 actually has 2 "native" encodings.

This patch resolves all of these issues.
new method -unicodeFilesystemRepresentation
fixed all win32 uses of filesystemRepresentation to use the new unicodeFilesystemRepresentation
fixed all of the occurances of a unicode string being passed to a ANSI api call

Jeremy Bettis <jeremybettis>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-11-06 CaS StatusNone Wont Do
    Open/ClosedOpen Closed
2005-11-04 jeremybettis Attached File- Added filesystemrep-unicode.patch.txt, #5435

Back to the top

Powered by Savane 3.13-caa5.
Corresponding source code