Re: [pdf-devel] [PATCH] Implement pdf_fsys_disk_item_p in base/pdf-fsys-disk.c [try 2]

[jemarch]

Hi Zac.

   > Maybe would be a good idea to write system-dependent path syntax
   > checking functions. Something like 'pdf_fsys_posix_path_name_p' and
   > 'pdf_fsys_w32_path_name_p'. What do you think?
   > 
   I think it would be a good idea. I will look into it.

Thanks.

   Windows is Unicode safe, they comply from UTF-7 up to
   UTF-32. Pre-Win2K NT platforms (most notably NT 4) do use UCS-2 so
   that can be incompatible.

Note that we should be able to manage that kind of systems too.

   As a solution (discussed between myself and jemarch), a work around
   is to always ask Windows to convert the string to UTF-16 since this
   is Windows preferred internal representation of data in unicode.

The text module can do that, using 'pdf_text_get_unicode' instead of
'pdf_text_get_host'.

   > How do 'FindFirstFile' manages relative paths? What is the "default"
   > volume used if the path does not contain a volume specification? Do it
   > support "device" filenames such as PRN?
   > 
   Relative paths are handled by the FindFirstFile facilities. I'm almost 
positive 
   the default volume used is that of the CWD. Regarding device
   filenames, I'm unsure.
 
Please check the volume issue. If you are right then it is not a
problem: the POSIX functions do the same when applying pwd.