Re: Using Perl's cc

[Gavin Smith]

On 5 July 2015 at 16:15, Eli Zaretskii <address@hidden> wrote:
>> Date: Sun, 5 Jul 2015 15:50:01 +0100
>> From: Gavin Smith <address@hidden>
>> Cc: address@hidden
>>
>> It would be nice to be able to fall back to using alternative
>> functions on other platforms as well, so I'd suggest not making it
>> Windows-specific.
>
> Windows provides an API for converting from UTF-8 to UTF-16, and I
> intended to use it.  Also, the functions that accept a wchar_t
> argument need to be different depending on whether wchar_t is UCS-4 or
> UTF-16.  I think this makes the code sufficiently different to warrant
> separate implementations.

I thought you would have to write your own iswupper etc. so using the
system's wchar_t doesn't gain you anything. If I was writing it
myself, I'd convert a single UTF-8 codepoint into a 32-bit integer (I
think that's UCS-4), and my iswupper would check its value. Of course,
if there are Windows functions you want to use, you may want to do it
differently.

>> Do you think the choice of which functions should be used can be made
>> at run-time, possibly in addition to a choice at build-time? For
>> example, if switching to a UTF-8 locale fails?
>
> Yes, I think so: which locales are installed on any particular system
> is not known in advance.  Granted, less and less Posix systems don't
> have a UTF-8 locale available, but I'm not sure this can be relied
> upon.
>
> Btw, the code currently asks for en_US.UTF-8, but what we actually
> need is for the codeset to be UTF-8, regardless of the locale, no?  So
> perhaps it's better not to ask for en_US, since it could be that
> locale is not available, but en_GB.UTF-8 (say) is.  Is it possible to
> call 'setlocale' to only switch the codeset?

By specifying "LC_CTYPE" it will switch the codeset only, but I doubt
it's possible to miss off the "en_US".

>> There's two big hurdles to running the extension module: one is
>> building it, which it looks like you will manage to do; but the other
>> is loading it from a running Perl instance, and I still don't know if
>> that will succeed.

> What are the hurdles?  I'd expect Perl to be able to load a .dll file
> on Windows exactly like it loads a .so file on Unix.  The only issue
> might be telling Perl to look in the directory where Texinfo's "make
> install" puts them, but I expect texi2any to take care of that
> already, no?

If it wasn't compiled properly, e.g. with the wrong flags or header
files. Perl may find the .dll file and load it and things may break
afterwards when the code in the extension runs.