GNUstep - Patches: patch #4598, filesystemRepresentation on Win32...
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: |
Richard Frith-Macdonald <CaS> |
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]
|
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*
|
Jeremy Bettis <jeremybettis> |
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | None | Wont Do | |
Open/Closed | Open | Closed | |||
2005-11-04 | jeremybettis | Attached File | - | Added filesystemrep-unicode.patch.txt, #5435 |
Powered by Savane 3.13-caa5.
Corresponding source code
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 ...
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.
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.
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.