On 03/02/2013 10:10 AM, John Goodyear wrote:
I noticed an issue while putting together a testcase for the compiler
group based on the problem in S_append_utf8_from_native_byte() in inline.h.
Tracing the macro dependencies, I found these in utfebcidic.h
#define NATIVE_UTF8_TO_I8(ch) (ch) PL_e2utf[(U8)(ch)]
#define I8_TO_NATIVE_UTF8(ch) (ch) PL_utf2e[(U8)(ch)]
Removing the redundant (ch) from each line got rid of the compiler error.
I've stared at that code lots trying to see if it was something we were
doing. And I completely missed it. Phew!
I'll now look at the rest
Running make -k gets 35 object modules compiled. Much better.
make -k error highlights:
/u/jgood/perlsrc/perl-92a582c >grep -v non-portable make.out | grep
-e ERROR -e "not created"
ERROR CCN3045 op.c:4131 Undeclared identifier ILLEGAL_UTF8_BYTE.
CCN0793(I) Compilation failed for file ./opmini.c. Object file not
created.
ERROR CCN3045 ./toke.c:3009 Undeclared identifier ILLEGAL_UTF8_BYTE.
CCN0793(I) Compilation failed for file ./toke.c. Object file not
created.
ERROR CCN3045 ./pp.c:3835 Undeclared identifier
LATIN_SMALL_LETTER_Y_WITH_DIAERESIS_NATIVE.
ERROR CCN3045 ./pp.c:3845 Undeclared identifier
LATIN_SMALL_LETTER_SHARP_S_NATIVE.
ERROR CCN3045 ./pp.c:4221 Undeclared identifier MICRO_SIGN_NATIVE.
ERROR CCN3045 ./pp.c:4244 Undeclared identifier
LATIN_SMALL_LETTER_SHARP_S_NATIVE.
CCN0793(I) Compilation failed for file ./pp.c. Object file not created.
ERROR CCN3045 ./utf8.c:1655 Undeclared identifier
LATIN_SMALL_LETTER_Y_WITH_DIAERESIS_NATIVE.
ERROR CCN3051 ./utf8.c:1657 Case expression must be a valid
integral constant.
ERROR CCN3045 ./utf8.c:1660 Undeclared identifier MICRO_SIGN_NATIVE.
ERROR CCN3051 ./utf8.c:1660 Case expression must be a valid
integral constant.
ERROR CCN3045 ./utf8.c:1663 Undeclared identifier
LATIN_SMALL_LETTER_SHARP_S_NATIVE.
ERROR CCN3051 ./utf8.c:1663 Case expression must be a valid
integral constant.
ERROR CCN3045 ./utf8.c:1784 Undeclared identifier MICRO_SIGN_NATIVE.
ERROR CCN3045 ./utf8.c:1787 Undeclared identifier
LATIN_SMALL_LETTER_SHARP_S_NATIVE.
ERROR CCN3045 ./utf8.c:4255 Undeclared identifier
FIRST_SURROGATE_UTF8_FIRST_BYTE.
CCN0793(I) Compilation failed for file ./utf8.c. Object file not
created.
ERROR CCN3045 op.c:4131 Undeclared identifier ILLEGAL_UTF8_BYTE.
CCN0793(I) Compilation failed for file ./op.c. Object file not created.
Here's the full make output. Other than the errors above. I just see
char** vs unsigned char** WARNINGS.
/(See attached file: make.out)/
Changes
As a temporary measure for long long support:
1) Added -Wc,"LANGLVL(LONGLONG) to os390.sh where foat(ieee) is
located
2) Modified Configure to pass -Wc,"LANGLVL(LONGLONG) in the
compile and compile_ok variables
Changed files
hints/os390.sh
utfebcdic.h
x2p/a2p.c (I take it this is generated by yacc.
make realclean and make distclean don't seem to remove it)
Configure
/(See attached file: 92a582c-diff.out)/
Regards,
John Goodyear
>
> John sent me a bunch of output. I chose to look at util.c because its
> relatively short. After deleting all the __inline__ warnings, there
> were just two left:
> ERROR CCN3277 ./util.c.c:23818 Syntax error: possible missing ';' or ','?
> ERROR CCN3277 ./util.c.c:23819 Syntax error: possible missing ';' or ','?
>
> The util.c.c file is what is generated by the preprocessor. The
> shortest of the errors is line 23819:
>
> *(*dest)++ = ((PL_e2a[(U8)(byte)] & ((U8)0x1f)) | 0xA0)
> PL_utf2e[(U8)((PL_e2a[(U8)(byte)] & ((U8)0x1f)) | 0xA0)];
>
>
> And yes there is a syntax error there. If you look at the balanced
> parens, you will note that the first set ends in the middle of the line,
> and then there is a space and then a PL_utf2e[...]; The latter is a
> complete subexpression going to the end of the line.
>
> So there are two expressions separated by a blank, indeed a syntax
> error. If you look carefully, that first expression is repeated as a
> component of the 2nd. It turns out that the correct expansion of the
> macro is just the 2nd expression. The 1st expression should not be
> there. The preprocessor is apparently outputting the results of an
> intermediate stage of its processing!
>
> I wonder if some developer left in a debug statement in the
> preprocessor. But surely it gets enough use that this would have been
> exposed long before now. So I don't know how to proceed. (Note that
> this bug would cause huge long expansions when shorter ones would be
> correct; if fixed, exceeding the apparent 2048 character limit might
> just go away.)
>
> I'm sending this to the whole list in case it rings a bell for someone.
>
