Yaribz has asked for the wisdom of the Perl Monks concerning the following question:

Hello, I noticed that one of my Perl scripts was generating truncated error messages when running on Windows. After some investigations, I found the problem was related to the way the Socket::getaddrinfo function returns the error message (maybe the same thing happens with Socket::getnameinfo).

Here is a code snippet to illustrate the problem:

require Socket; # socktype is set to -1 to make getaddrinfo return an error my ($gaiErr)=Socket::getaddrinfo('perl.org',80,{socktype => -1}); my ($osErr,$extErr)=($!,$^E); print "\$gaiErr=\"$gaiErr\" (".($gaiErr+0).")\n"; print "\$osErr=\"$osErr\" (".($osErr+0).")\n"; print "\$extErr=\"$extErr\" (".($extErr+0).")\n";

Here is what it returns when I run it on a Windows 10 21H1 19043.1586 system (configured in French), with Strawberry Perl 5.32.1-64bit:

$gaiErr="La prise en charge du type de socket spécifié n" (10044) $osErr="Illegal byte sequence" (42) $extErr="La prise en charge du type de socket spécifié n’existe pas da +ns cette famille d’adresses" (10044)

The error message contained in $gaiErr is truncated. It looks like at some point the getaddrinfo function tried to parse/process the error message returned by the corresponding Win32 API call, but it stopped when it encountered the "typographic apostrophe" / "right single quotation mark" character. I guess it didn't use the correct encoding (afaik it should use the Windows ANSI code page of the system). Note that in this case the $^E variable contains the entire correct error message...

For reference, here is the result when I run the same code on a Linux system:

$gaiErr="ai_socktype non supporté" (-7) $osErr="No such file or directory" (2) $extErr="No such file or directory" (2)

This is the result I expected on Windows: the $gaiErr variable contains the entire error message, no need to check $! or $^E (which contains unrelated information in this case).

Maybe it is possible to workaround the problem by adding a line like this one (just after the getaddrinfo call):

$gaiErr=$^E=$gaiErr if($gaiErr && $^O eq 'MSWin32');

But I'm not sure it would always work (it would require all getaddrinfo error code values to be "compatible" with $^E). And anyway it seems a bit ugly... Did I miss something here? Also, is there a way to force usage of unlocalized error messages on Windows from a Perl script?

Thanks !

Replies are listed 'Best First'.
Re: Socket::getaddrinfo and localized error messages on Windows
by syphilis (Archbishop) on Apr 23, 2022 at 13:58 UTC
    I'm not sure how (if) this helps but, with the same build of 64-bit Strawberry Perl-5.32.1 on Windows 7, this is what the same snippet of code outputs for me:
    C:\_32\pscrpt\socket>perl try.pl $gaiErr="The support for the specified socket type does not exist in t +his address family. " (10044) $osErr="Result too large" (34) $extErr="The support for the specified socket type does not exist in t +his address family" (10044)
    No truncation of $gaiErr, a different $osErr, and effectively the same $extErr.

    Cheers,
    Rob

      Yes in your case the localized error message generated in this example doesn't use any non ASCII characters, so the bug isn't triggered. Depending on the system language (and the system ANSI code page) I guess it can be easier or harder to trigger the bug. However for some reason in your case $gaiErr contains a dot and an extra space at the end of the string compared to $extErr.

      Thanks anyway for trying to reproduce !

        However for some reason in your case $gaiErr contains a dot and an extra space at the end of the string compared to $extErr

        Yes, I noticed that, too ... and wondered ...

        I think you should create an issue of this.
        If the problem turns out to be in 'cpan/Socket' (in the perl source) you would then have to file a bug report against the Socket distro, but I'm guessing that the problem lies in some windows-specific section of the perl source that is outside of 'cpan/Socket' - more likely in the 'win32' folder of the perl source.

        Of course, you might yet receive some helpful responses here, explaining the nature of the problem.

        Cheers,
        Rob