[patch #4598] filesystemRepresentation on Win32 is DANGEROUS as implemented

[Richard Frith-Macdonald]

Update of patch #4598 (project gnustep):

                  Status:                    None => Wont Do                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up 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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?func=detailitem&item_id=4598>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/