Perl headers severely warn on format strings on GCC C++11 -Wliteral-suffix #13451
Comments
From @bulk88Created by @bulk88Perl's headers when compiled with GCC with -std=c++0x gives tons of Perl Info |
From @jkeenanOn Tue Dec 03 04:56:58 2013, bulk88 wrote:
[snip many more warnings] bulk88, There are many variables which could be leading to this result: * the OS -- cygwin is not one of our most often tested systems; * the GCC version -- this is quite new, correct? * your configuration arguments I don't have cygwin or that recent a GCC available. On dromedary (Linux x86_64), we have: ##### I configured blead as follows: ##### That's about as close as I could come to your configuration. I got no 'invalid suffix' warnings. Could you try this with, say, other versions of GCC to see if the compiler version is the explanatory variable? Thank you very much. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @craigberryOn Tue, Dec 3, 2013 at 9:29 PM, James E Keenan via RT
It's readily reproducible configuring with $ ./Configure -Dusedevel -Dcc=g++ -Accflags=-std=c++0x -des on $ g++ -v I don't understand why it thinks format specifiers are identifiers but |
From @tonycozOn Tue Dec 03 04:56:58 2013, bulk88 wrote:
I can reproduce this on blead (5.14 isn't supported.) I guess this means we'll need to start putting spaces around UVxf and friends.
They're used for user-defined literals[1] in C++, which only allows name starting with underscores. http://en.wikipedia.org/wiki/C++11#User-defined_literals So you can define: // I have no idea if this is the correct syntax then initialize objects with those literals instead of hoping the right constructor Date foo = "2013-12-04"_date; Tony [1] which I don't claim to understand at this point |
From perl5-porters@perl.orgTony Cook wrote:
I think it would be worth simply suppressing that warning. |
From @tonycozOn Wed Dec 04 04:08:55 2013, perl5-porters@perl.org wrote:
If the C++ standard disallows "foo"BAR and we want our headers to be usable from C++, then we need to fix the headers. Compilers are only required to produce a diagnostic for non-conforming code, which is what g++ is doing in this case, but another compiler can correctly reject the code entirely with an error and prevent compilation of the unit entirely. I don't think we need to worry about the same warning in a .c file. I'll produce a fix for the headers. Tony |
From @bulk88On Tue Dec 03 20:36:35 2013, tonyc wrote:
From what I understand is the C++11 feature is, in C you can suffix literals with l/L/f/F/u/U/i64 to change their type, but those are all hard coded into C compiler. Now you can define/hook your own suffixes for literals not just l/L/f/F/u/U/i64. Operator overloading was extended to the suffixes for literals. If they add prefix overloading and a couple other things, soon C++ will have the ability to compile Perl code after you "#include <perlpp>" jkjk -- |
From @bulk88On Mon Dec 09 21:24:41 2013, tonyc wrote:
The header warnings are a real bug if someone writes C++11 xsubs or links to a C++11 C++ lib. But a 2nd problem of much less priority is some p5pers compile the interp's .c files in C++ mode (year unspecified, probably C++03 or older), and the interp usually builds successfully in C++ mode (atleast on Win32 for me with Visual C >6). I'm not sure if the CORE XS modules compile with g++ on *nix or not. So are the .c files C++11 compatible or not? This ticket isn't about whether the core .c files are C++ okay (so when the headers are made warning free on G++ 11 it can be closed), but this post is just a reminder about the practice. -- |
From @LeontOn Tue, Dec 10, 2013 at 6:55 AM, bulk88 via RT <perlbug-followup@perl.org>wrote:
Actually, given I've previously written libperl++, that «auto foo = Leon |
From @tonycozOn Mon Dec 09 21:24:41 2013, tonyc wrote:
The attached fixes all the core headers. ppport.h is producing literal suffix warnings too, but I'm not sure whether Tony |
From @tonycoz0001-perl-120670-make-perl-headers-C-11-compatible.patchFrom 7f719bd6cfc1d99e0b5ada8f878ad1dfe09bd9c9 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@saturn.(none)>
Date: Wed, 11 Dec 2013 09:48:15 +1100
Subject: [PATCH] [perl #120670] make perl headers C++11 compatible
---
inline.h | 2 +-
pad.h | 10 +++++-----
perl.h | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/inline.h b/inline.h
index 226970b..518d8da 100644
--- a/inline.h
+++ b/inline.h
@@ -244,7 +244,7 @@ S_bootstrap_ctype(U8 character, UV classnum, bool full_Latin1)
default: break;
}
- Perl_croak(aTHX_ "panic: bootstrap_ctype() has an unexpected character class '%"UVxf"'", classnum);
+ Perl_croak(aTHX_ "panic: bootstrap_ctype() has an unexpected character class '%" UVxf "'", classnum);
}
#endif
diff --git a/pad.h b/pad.h
index 32bdb61..564e783 100644
--- a/pad.h
+++ b/pad.h
@@ -143,14 +143,14 @@ typedef enum {
# define ASSERT_CURPAD_LEGAL(label) \
pad_peg(label); \
if (PL_comppad ? (AvARRAY(PL_comppad) != PL_curpad) : (PL_curpad != 0)) \
- Perl_croak(aTHX_ "panic: illegal pad in %s: 0x%"UVxf"[0x%"UVxf"]",\
+ Perl_croak(aTHX_ "panic: illegal pad in %s: 0x%" UVxf "[0x%" UVxf "]",\
label, PTR2UV(PL_comppad), PTR2UV(PL_curpad));
# define ASSERT_CURPAD_ACTIVE(label) \
pad_peg(label); \
if (!PL_comppad || (AvARRAY(PL_comppad) != PL_curpad)) \
- Perl_croak(aTHX_ "panic: invalid pad in %s: 0x%"UVxf"[0x%"UVxf"]",\
+ Perl_croak(aTHX_ "panic: invalid pad in %s: 0x%" UVxf "[0x%" UVxf "]",\
label, PTR2UV(PL_comppad), PTR2UV(PL_curpad));
#else
# define ASSERT_CURPAD_LEGAL(label)
@@ -324,7 +324,7 @@ Restore the old pad saved into the local variable opad by PAD_SAVE_LOCAL()
PL_comppad = (PAD*) (PadlistARRAY(padlist)[nth]); \
PL_curpad = AvARRAY(PL_comppad); \
DEBUG_Xv(PerlIO_printf(Perl_debug_log, \
- "Pad 0x%"UVxf"[0x%"UVxf"] set_cur depth=%d\n", \
+ "Pad 0x%" UVxf "[0x%" UVxf "] set_cur depth=%d\n", \
PTR2UV(PL_comppad), PTR2UV(PL_curpad), (int)(nth)));
@@ -342,7 +342,7 @@ Restore the old pad saved into the local variable opad by PAD_SAVE_LOCAL()
PL_comppad = (npad); \
PL_curpad = PL_comppad ? AvARRAY(PL_comppad) : NULL; \
DEBUG_Xv(PerlIO_printf(Perl_debug_log, \
- "Pad 0x%"UVxf"[0x%"UVxf"] save_local\n", \
+ "Pad 0x%" UVxf "[0x%" UVxf "] save_local\n", \
PTR2UV(PL_comppad), PTR2UV(PL_curpad)));
#define PAD_RESTORE_LOCAL(opad) \
@@ -350,7 +350,7 @@ Restore the old pad saved into the local variable opad by PAD_SAVE_LOCAL()
PL_comppad = opad; \
PL_curpad = PL_comppad ? AvARRAY(PL_comppad) : NULL; \
DEBUG_Xv(PerlIO_printf(Perl_debug_log, \
- "Pad 0x%"UVxf"[0x%"UVxf"] restore_local\n", \
+ "Pad 0x%" UVxf "[0x%" UVxf "] restore_local\n", \
PTR2UV(PL_comppad), PTR2UV(PL_curpad)));
diff --git a/perl.h b/perl.h
index 2d98004..b7c5b8b 100644
--- a/perl.h
+++ b/perl.h
@@ -3033,7 +3033,7 @@ typedef pthread_key_t perl_key;
/* Takes three arguments: is_utf8, length, str */
#ifndef UTF8f
-# define UTF8f "d%"UVuf"%4p"
+# define UTF8f "d%" UVuf "%4p"
#endif
#define UTF8fARG(u,l,p) (int)cBOOL(u), (UV)(l), (void*)(p)
@@ -4122,7 +4122,7 @@ START_EXTERN_C
EXTCONST char PL_warn_uninit[]
INIT("Use of uninitialized value%s%s%s");
EXTCONST char PL_warn_uninit_sv[]
- INIT("Use of uninitialized value%"SVf"%s%s");
+ INIT("Use of uninitialized value%" SVf "%s%s");
EXTCONST char PL_warn_nosemi[]
INIT("Semicolon seems to be missing");
EXTCONST char PL_warn_reserved[]
@@ -4142,7 +4142,7 @@ EXTCONST char PL_no_usym[]
EXTCONST char PL_no_aelem[]
INIT("Modification of non-creatable array value attempted, subscript %d");
EXTCONST char PL_no_helem_sv[]
- INIT("Modification of non-creatable hash value attempted, subscript \"%"SVf"\"");
+ INIT("Modification of non-creatable hash value attempted, subscript \"%" SVf "\"");
EXTCONST char PL_no_modify[]
INIT("Modification of a read-only value attempted");
EXTCONST char PL_no_mem[sizeof("Out of memory!\n")]
--
1.7.9
|
From @bulk88On Tue Dec 10 14:52:50 2013, tonyc wrote:
I'm not in a position to test this patch. I'll assume all of literal suffix format string warning in the headers was fixed, and not just the line numbers in my sample from a 5.14 perl trying to compile an XS library. So don't wait for confirmation from me that this patch fixes the warnings. -- |
From @tonycozOn Tue Dec 10 14:52:50 2013, tonyc wrote:
Applied to blead, I'll make patch for Devel-PPPort. Tony |
From @tonycozOn Wed Jan 15 18:17:28 2014, tonyc wrote:
Sent upstream as https://rt.cpan.org/Ticket/Display.html?id=92188. Tony |
From @bulk88On Wed Jan 15 19:15:56 2014, tonyc wrote:
Dual-Life/Devel-PPPort#1 it was merged but doesn't look like it has gotten a new CPAN release https://github.com/mhx/Devel-PPPort/commits/master so there is nothing to sync back to blead yet, do we want a new PPPort to ship with 5.20? I think needs a perldelta entry too. -- |
From @tonycozOn Fri Mar 07 16:02:11 2014, bulk88 wrote:
The merge of Devel-PPPort 3.22 solves the last remaining part of this issue. I don't think it needs a perldelta entry. Tony |
|
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#120670 (status was 'resolved')
Searchable as RT120670$
The text was updated successfully, but these errors were encountered: