I'd go with either MathInt64 or UseMathInt64.

I think I'd default the setting to 'on' if you're using a perl that doesn't support quads.

Making it the default would require trying to load Math::Int64, and I can understand being reluctant to do that. Also, using it or not gives quite incompatible results so I don't think it should be too automatic. I'd leave it 'off' by default but I'd also make turning it 'on' fatal if Math::Int64 hasn't already been loaded.

I agree with not returning an empty string for the failure case. I also don't like the name SafeReadWideCString(). Having a safe way to do it is certainly a big part of the motivation for providing this, but I don't find that worthy of inclusion in the name. Adding "C" as short for "Character" is as likely to be confusing as anything. 'Read' sounds more like an I/O operation than a memory operation.

CopyWideToUtf8() works better for me for what you described. But I would personally appreciate having the ability to copy out the WCHAR string separate from the "convert to utf-8". If I'm going to make a bunch of WCHAR API calls, I may not want to convert the WCHAR to utf-8 just to have to convert it back again in order to pass it along to the next API. So maybe CopyWideString() also or CopyWideString() with an option to specify conversion or not.

PWCHARtoPV()? Just kidding.

I also like just being able to have 64-bit integers converted to/from NVs (double). For a huge range of values, there is no data loss. For some values, you lose some less-significant bits (which can be inappropriate for some uses but often is not a problem). I can certainly see not making this the default, of course.

tye:

For the default thing, I was thinking along the lines of leaving the setting to "on", but only load Math::Int64 on demand. In other words, I was hoping to *not* load it until someone actually defined an API using 'q'. But that would likely overcomplicate things.

An alternative suggestion: If Math::Int64 is loaded and you're on a perl without quad support, *then* set the default to yes. Does that sound a bit more reasonable?

Update: Ever since my eye trouble, I notice myself missing things. On re-reading, I notice that you already suggested my alternative proposal. (Note: Don't get a retinal tear. They suck. Six months later, and my left eye *still* looks like I'm looking through a snow-globe.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

An alternative suggestion: If Math::Int64 is loaded and you're on a perl without quad support, *then* set the default to yes. Does that sound a bit more reasonable?

Is probing ::VERSION or %INC the really right way to do things and changing your behavior based on what PMs are already in the process really a good idea?

What if module A is loaded by main::, which uses Win32::API internally, loads Math::Int64 and uses the quads as Math::Int64 objects, then module B is loaded by main::, which uses Win32::API internally, does not load Math::Int64, and uses quads as 8 byte strings, now module B will fatally error since it didn't pass a Math::Int64 to Win32::API and instead passed a 8 byte string quad, because of the global probing of what modules are already loaded into the process.

One solution to this problem in a non-Perl setting I saw was, to create a root "global settings" object, and then the main object is generated from a root global settings object. Each module/Library creates usually 1 global settings object for itself, but this way the global settings are library specific, not really global to the process. I dont know what to think about this solution. caller probing for the caller's stash and maintain a "global" settings DB for each caller's stash, or caller peeking in Perl is too unreliable and unprofessional?

Adding "C" as short for "Character" is as likely to be confusing as anything.

I added the C since its only for Wide C strings, not Wide length tracked strings, for length tracked wide strings just use ReadMemory/memcpy to a scalar.

I also like just being able to have 64-bit integers converted to/from NVs (double). For a huge range of values, there is no data loss. For some values, you lose some less-significant bits (which can be inappropriate for some uses but often is not a problem). I can certainly see not making this the default, of course.

Risk of unintentional data/high bit loss is nearly guaranteed for someone who doesn't know C/perlguts and 2^53 limit.

PWCHARtoPV()? Just kidding.

I've been thinking about BADLPCWSTRTOMBCSPV jkjk.