Re: Filename Encoding

[John Darrington]

On Mon, Dec 09, 2013 at 08:30:17PM -0800, Ben Pfaff wrote:
     On Sun, Dec 08, 2013 at 07:43:25PM +0100, John Darrington wrote:
     > Thanks to Harry's feedback, I've started to understand the issues 
concerning 
     > bug #33255 .
     
     Can you explain the issue as you see it?  I don't see any recent
     substantive comments in that bug report.


There are two issues when dealing with filenames on windows.

Firstly, if not using ascii, it is unsafe to open a file using fopen.  Instead,
one must convert the filename to a wchar_t (UTF16) and use the special windows 
function _wfopen.  However, if you want to convert a string to UTF16, you have 
to know what encoding the string currently is.

Now the filename for (say) a GET FILE command can in PSPP come from a variety 
of 
sources:

* From a syntax file.  In which case the filename is presumably in the encoding
  of the file.

* From the command line.  In which case the encoding is probably that of the 
  current locale.

* From the GUI.  In which case, the encoding is either UTF-8  or the value of 
  G_FILENAME_ENCODING See 
https://developer.gnome.org/glib/stable/glib-running.html


Since there are many different sources of a filename, unless we know the 
source, we
cannot know the encoding.
  
So my proposed solution is to save the encoding and the filename together in a 
struct,
and pass them around in that struct.  Fortunately, we already have such a 
struct which
is in most cases used to open/close/access files, viz; struct file_handle.

I hope this makes sense.


J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature