On Tue, Jun 16, 2015 at 01:12:13PM +0100, Aaron Crane wrote:
> I'm afraid I can't directly answer those questions, but I have looked
> into where the problems lie. As far as I can tell, the only thing that
> fails under -pedantic is Encode. Specifically, Encode's enc2xs program
> generates files like cpan/Encode/Byte/byte_t.c that look roughly like
> this (massively cut down here):
>
> static const encpage_t utf8_AdobeStandardEncoding[];
> static const encpage_t utf8_AdobeStandardEncoding_c4[2] = {
> {enctable + 3856,utf8_AdobeStandardEncoding,0xb1,0xb1,1,1},
> {0,utf8_AdobeStandardEncoding_c4,0xb2,0xff,0,0},
> };
> static const encpage_t utf8_AdobeStandardEncoding[10] = { /* elided */ };
>
> That is, the generated code has variables whose initialisations refer
> to each other. In this case, the "utf8_AdobeStandardEncoding_c4"
> variable (note trailing "_c4") has an initialisation that refers to
> "utf8_AdobeStandardEncoding" (with no trailing bit). The first
> declaration tries to declare a static array with no size or
> initializer (the empty square brackets) as a forward declaration to be
> used by the "c4" declaration. GCC apparently rejects this under
> -pedantic:
>
> byte_t.c:9:24: error: array size missing in 'utf8_AdobeStandardEncoding'
> static const encpage_t utf8_AdobeStandardEncoding[];
> ^
> byte_t.c:9:24: warning: uninitialized const
> 'utf8_AdobeStandardEncoding' is invalid in C++ [-Wc++-compat]
>
> byte_t.c:867:24: error: conflicting types for 'utf8_AdobeStandardEncoding'
> static const encpage_t utf8_AdobeStandardEncoding[10] = {
>
> byte_t.c:9:24: note: previous declaration of
> 'utf8_AdobeStandardEncoding' was here
> static const encpage_t utf8_AdobeStandardEncoding[];
>
> I don't know whether GCC is correct here. If we assume it is, and we
> want to be able to build under -pedantic (and under other compilers
> that enforce the same restriction), then I think the solution would be
> for enc2xs to topologically sort the graph of variables before
> emitting them, rather than relying on these forward declarations.
Unfortunately its not as simple as that. The tables contain recursive and
mutually recursive pointers to other tables.
I've just pushed the following for smoking which hopefully fixes it.
commit 10028d8ed0c8763a2d1a55cc9ec86ef07b57d2ef
Author: David Mitchell <da...@iabyn.com>
AuthorDate: Tue Jun 23 11:12:40 2015 +0100
Commit: David Mitchell <da...@iabyn.com>
CommitDate: Tue Jun 23 11:21:04 2015 +0100
make Encode compile under -pedantic
enc2xs generates some C code which contains tables. These tables contain
recursive and mutually recursive pointers to other tables. Normally they
are declared as 'static const', except under C++ which can't handle this,
so there they are declared 'extern' and defined ''.
-Wc++-compat and -pedantic put a bit of a spanner in the works.
There is an existing hack to shut up a warning with -Wc++-compat by not
including the table's size in the forward declaration, but this breaks
-pedantic.
This commit does two things to enc2xs. First it moves all the logic that
examines the build options and decides whether to use 'const' etc, into
a separate function, compiler_info(). Second, it fixes the -pedantic
compilation failure by, in the presence of both -Wc++-compat and
-pedantic, falling back to a C++-style compile without the 'static const'.
This is monkey-patching an unstream-CPAN module in core due to it failing
one of the smoke configurations.
--
The crew of the Enterprise encounter an alien life form which is
surprisingly neither humanoid nor made from pure energy.
-- Things That Never Happen in "Star Trek" #22
