Skip to content

[Win32] perl.h remaps 'strtoll' and 'strtoull' incorrectly #16074

Closed
Closed
[Win32] perl.h remaps 'strtoll' and 'strtoull' incorrectly#16074

Description

@p5pRT
p5pRT
opened on Jul 9, 2017

Migrated from rt.perl.org#131726 (status was 'resolved')

Searchable as RT131726$

Activity

  1. p5pRT commented on Jul 9, 2017

    @p5pRT
    p5pRT
    on Jul 9, 2017
    Author

    From @sisyphus

    Hi,

    The bug has been reported to the WX queue (
    https://rt.cpan.org/Ticket/Display.html?id=121683 ) and to the
    Perl-Dist-Strawberry queue (
    https://rt.cpan.org/Ticket/Display.html?id=122353 )
    The WX thread contains this patch which seems fine to me​:

    ####################################
    --- /c/users/keckhard/Downloads/Perl/perl-5.26.0/perl.h 2017-05-30
    09​:58​:05 +0000
    +++ /c/perl5/perl/lib/CORE/perl.h 2017-06-16 10​:02​:58 +0000
    @​@​ -6261,7 +6261,7 @​@​
      # ifdef __hpux
      # define strtoll __strtoll /* secret handshake */
      # endif
    -# ifdef WIN64
    +# if defined(WIN64) && defined(_MSC_VER)
      # define strtoll _strtoi64 /* secret handshake */
      # endif
      # if !defined(Strtol) && defined(HAS_STRTOLL)
    @​@​ -6295,7 +6295,7 @​@​
      # ifdef __hpux
      # define strtoull __strtoull /* secret handshake */
      # endif
    -# ifdef WIN64
    +# if defined(WIN64) && defined(_MSC_VER)
      # define strtoull _strtoui64 /* secret handshake */
      # endif
      # if !defined(Strtoul) && defined(HAS_STRTOULL)
    ####################################

    I've also struck the issue trying to build Audio​::TagLib-1.67 on
    perl-5.26.0.

    IME it's only 64-bit builds of perl-5.26.0 that are afflicted.
    Furthermore, having built 64-bit perl-5.26.0 with mingw ports of gcc-5.3.0,
    gcc-6.3.0 and gcc-7.1.0, I'm finding that there's no such issue when
    gcc-5.3.0 is used.
    Apparently, changes made to the mingw x64 ports some time after 5.3.0 and
    before 6.3.0 are contributing factors.

    Simplest way of reproducing the failure that I could come up with was to
    compile this script​:

    /***********************/
    #include "EXTERN.h"
    #include "perl.h"

    #include <string>

    int main() {
      return 0;
    }

    /***********************/
    with​:
    g++ -c -IC​:/path/to/perl/lib/CORE try.cpp

    Can this be fixed (as per the patch provided by the WX thread) for
    perl-5.26.1 ?

    Cheers,
    Rob

  2. p5pRT commented on Jul 9, 2017

    @p5pRT
    p5pRT
    on Jul 9, 2017
    Author

    From @jkeenan

    On Sun, 09 Jul 2017 14​:40​:52 GMT, sisyphus wrote​:

    Hi,

    The bug has been reported to the WX queue (
    https://rt.cpan.org/Ticket/Display.html?id=121683 ) and to the
    Perl-Dist-Strawberry queue (
    https://rt.cpan.org/Ticket/Display.html?id=122353 )
    The WX thread contains this patch which seems fine to me​:

    ####################################
    --- /c/users/keckhard/Downloads/Perl/perl-5.26.0/perl.h 2017-05-30
    09​:58​:05 +0000
    +++ /c/perl5/perl/lib/CORE/perl.h 2017-06-16 10​:02​:58 +0000
    @​@​ -6261,7 +6261,7 @​@​
    # ifdef __hpux
    # define strtoll __strtoll /* secret handshake */
    # endif
    -# ifdef WIN64
    +# if defined(WIN64) && defined(_MSC_VER)
    # define strtoll _strtoi64 /* secret handshake */
    # endif
    # if !defined(Strtol) && defined(HAS_STRTOLL)
    @​@​ -6295,7 +6295,7 @​@​
    # ifdef __hpux
    # define strtoull __strtoull /* secret handshake */
    # endif
    -# ifdef WIN64
    +# if defined(WIN64) && defined(_MSC_VER)
    # define strtoull _strtoui64 /* secret handshake */
    # endif
    # if !defined(Strtoul) && defined(HAS_STRTOULL)
    ####################################

    I've also struck the issue trying to build Audio​::TagLib-1.67 on
    perl-5.26.0.

    IME it's only 64-bit builds of perl-5.26.0 that are afflicted.
    Furthermore, having built 64-bit perl-5.26.0 with mingw ports of gcc-5.3.0,
    gcc-6.3.0 and gcc-7.1.0, I'm finding that there's no such issue when
    gcc-5.3.0 is used.
    Apparently, changes made to the mingw x64 ports some time after 5.3.0 and
    before 6.3.0 are contributing factors.

    Simplest way of reproducing the failure that I could come up with was to
    compile this script​:

    /***********************/
    #include "EXTERN.h"
    #include "perl.h"

    #include <string>

    int main() {
    return 0;
    }

    /***********************/
    with​:
    g++ -c -IC​:/path/to/perl/lib/CORE try.cpp

    Can this be fixed (as per the patch provided by the WX thread) for
    perl-5.26.1 ?

    Is this a regression from earlier versions of Perl? If not, then AFAIK it would not qualify for perl-5.26.1.

    Thank you very much.
    --
    James E Keenan (jkeenan@​cpan.org)

  3. p5pRT commented on Jul 9, 2017

    @p5pRT
    p5pRT
    on Jul 9, 2017
    Author

    The RT System itself - Status changed from 'new' to 'open'

  4. p5pRT commented on Jul 9, 2017

    @p5pRT
    p5pRT
    on Jul 9, 2017
    Author

    From @cpansprout

    On Sun, 09 Jul 2017 08​:13​:20 -0700, jkeenan wrote​:

    Is this a regression from earlier versions of Perl? If not, then
    AFAIK it would not qualify for perl-5.26.1.

    perlpolicy.pod explicitly allows portability fixes.

    --

    Father Chrysostomos

  5. p5pRT commented on Jul 10, 2017

    @p5pRT
    p5pRT
    on Jul 10, 2017
    Author

    From @sisyphus

    -----Original Message-----
    From​: James E Keenan via RT
    Sent​: Monday, July 10, 2017 1​:13 AM
    To​: OtherRecipients of perl Ticket #131726​:
    Cc​: perl5-porters@​perl.org
    Subject​: [perl #131726] [Win32] perl.h remaps 'strtoll' and 'strtoull'
    incorrectly

    On Sun, 09 Jul 2017 14​:40​:52 GMT, sisyphus wrote​:

    Hi,

    The bug has been reported to the WX queue (
    https://rt.cpan.org/Ticket/Display.html?id=121683 ) and to the
    Perl-Dist-Strawberry queue (
    https://rt.cpan.org/Ticket/Display.html?id=122353 )
    [snip]
    Is this a regression from earlier versions of Perl? If not, then AFAIK it
    would not qualify for perl-5.26.1.

    The offending perl.h code goes back as far as 5.18.0 (perhaps further), and
    the assertion in my initial post that only 64-bit builds of perl-5.26.0 are
    affected may well be incorrect.
    It's probable (untested) that earlier versions of perl are similarly
    afflicted if built with a "sufficiently recent" 64-bit mingw compiler (eg
    gcc-6.3.0, gcc-7.1.0).

    It would therefore be best if the patch could also be applied to any future
    releases of earlier perl branches.

    Cheers,
    Rob

  6. p5pRT commented on Jul 27, 2017

    @p5pRT
    p5pRT
    on Jul 27, 2017
    Author

    From @steve-m-hay

    Thanks for the report and the pointer to the fix. This is now in blead as commit 8ed77d1.

    I've added my vote for it to the 5.24 and 5.26 voting files, under the guise of "Portability fixes" as suggested above, even though it doesn't quite fit the perlpolicy description of, "changes to Configure and the files in the hints/ folder." (They're only meant as examples, not as a complete list of what's allowed.)

  7. p5pRT commented on Jul 27, 2017

    @p5pRT
    p5pRT
    on Jul 27, 2017
    Author

    @steve-m-hay - Status changed from 'open' to 'resolved'

  8. p5pRT
    closed this as completedon Jul 27, 2017

  9. p5pRT commented on Jul 28, 2017

    @p5pRT
    p5pRT
    on Jul 28, 2017
    Author

    From @xsawyerx

    On 07/27/2017 07​:23 PM, Steve Hay via RT wrote​:

    Thanks for the report and the pointer to the fix. This is now in blead as commit 8ed77d1.

    I've added my vote for it to the 5.24 and 5.26 voting files, under the guise of "Portability fixes" as suggested above, even though it doesn't quite fit the perlpolicy description of, "changes to Configure and the files in the hints/ folder." (They're only meant as examples, not as a complete list of what's allowed.)

    Added my votes to it.

  10. p5pRT
    added
    Severity Low
    on Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions