Hi Alan
For this case the strings are hard coded somewhere in our code I think as the
only thing that is passed is the driver dll name e.g. "ps" or "svg" etc. which
are all plain ascii. I therefore don't think there is any interaction with user
code for the input to LoadLibrary. This is why I simply made the change to
LoadLibraryA.
Now I might have this wrong but from memory UTF8 is a superset of ascii, so if
the input was UTF8 encoded this should still be fine. However it is possible in
Visual Studio to change the file encoding from ascii (default) to UTF16. I
don't exactly know how this works - it may mean that all string literals become
UTF16 encoded. I consider this very much an edge case as it would require
someone to deliberately change the encoding. I have only ever done it when I
have pasted an non-ascii text into VS and I get prompted to change the
encoding. I also think that is someone did this then the LoadLibrary call would
probably be the least of our worries.
Regarding your other questions in the other email, I will try to investigate
when I can.
Phil
________________________________
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: Arjen Markus <arjen.mar...@deltares.nl>
Cc: Phil Rosenberg <philip_rosenb...@yahoo.com>; PLplot development list
<Plplot-devel@lists.sourceforge.net>
Sent: Tuesday, 23 September 2014, 16:39
Subject: Re: [Plplot-devel] tcl build problem
On 2014-09-23 10:36-0000 Arjen Markus wrote:
> Hi Phil,
> I will definitely try these changes with Cygwin and MinGW. Pairs of
functions for handling ASCII and UNICODE strings are ubiquitous under
Windows and I do not expect trouble like Cygwin or MinGW not
supporting the two flavours. Still, that needs to be checked.
To Arjen and Phil:
To interject one additional consideration here, user input to PLplot
on both Unix and Windows should be in the UTF-8 encoding of unicode,
but the actual strings containing those UTF-8 bytes are assumed by our
code to be contained in ordinary char * strings and NOT wide
characters. That's the whole point of UTF-8, it doesn't require wide
characters to contain it. Instead, the number of UTF-8 characters
encoded as bytes in a normal string is sometimes less (if two or more
bytes are used in a character encoding) than the number of bytes in
the string, but that is not an issue for us since all our string
processing of user input simply requires a NULL byte at the end to
mark the end of the UTF-8 string.
Note, we actually do no internal text rendering using the raw user
UTF-8 input. Instead, in all cases we immediately translate that char
* user input from UTF-8 to PLUNICODE (32-byte integer) arrays, and use
those PLUNICODE arrays internally for the text rendering.
So I am virtually positive when there is a Windows macro choice
between normal (so-called ascii) and wide characters anywhere in our
code, than in most (or all?) cases, that choice should be replaced by
the definite narrow version similar to the change Phil just did for
the src/ltdl_win32.c case.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
