Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Jul 9, 2017 · 8 comments
Closed

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

p5pRT opened this issue Jul 9, 2017 · 8 comments
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jul 9, 2017

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

Searchable as RT131726$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 9, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 9, 2017

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)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 9, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 9, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 10, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 27, 2017

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.)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 27, 2017

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

@p5pRT p5pRT closed this Jul 27, 2017
@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 28, 2017

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.

@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.