develooper Front page | perl.perl5.porters | Postings from February 2013

Re: New EBCDIC branch available

From:
Karl Williamson
Date:
February 27, 2013 05:21
Subject:
Re: New EBCDIC branch available
Message ID:
512D97D6.5000809@khwilliamson.com
On 02/26/2013 08:41 PM, John Goodyear wrote:
> Karl,
> I pulled down a snapshot from the link you provided.
>
> Here is the configure output: of
>
>     sh ./Configure -Dprefix=/u/jgood/local -Dusedl -Dusedevel -de >
>     configure.out 2>&1&
>
>
> /(See attached file: configure.out)/
>
>
> WRT to the errors previously seen during the makedepend step, besides
> the errors about missing headers which don't yet exist in the makedepend
> phase, the only remain error is:
>
>   2002  Finding dependencies for pp_sys.o.
>    2003  ERROR CCN3010 ./time64.c:478   Macro PeRl_CaTiFy invoked with a
> null argument for parameter a.
>    2004  ERROR CCN3010 ./time64.c:478   Macro PeRl_CaTiFy invoked with a
> null argument for parameter a.
>
> However,there is a new wrinkle.   the grep issued from cppstdin causes
> this notification for each source file:
>
>     grep: FSUM9950 input lines truncated - result questionable
>
> Apparently grep is limited to 2048 bytes.    The workaround is to use
> fgrep instead.   I did the replacement of grep for fgrep in cppstdin,
> and the error went away.    I see Configure is conditionalized for AIX,
> so perhaps adding another condition for z/OS.   However the questions are
>
>     1)  is is what changed to cause this to suddenly appear?
>     2) do you have line limit issues on any other platforms?   (another
>     one discussed further below for inline.h

It's possible that joining continued lines together caused lines to 
exceed you 2048 limit.  There are limits on other platforms.  I remember 
demerphq changing a macro generator to avoid exceeding a certain size, 
but I don't remember what that number is.  The line joining could be 
changed to remove trailing/leading blanks when doing the join.  That 
would cut the frequency of the errors
>
>
> Getting to the compile, I get roughly 1500 of these CCN4108
>   informationals for every time __attribute__ is seen when compiling a file:
>
>     INFORMATIONAL CCN4108 ./proto.h:4534  The use of keyword
>     '__attribute__' is non-portable.
>
>
> If we are comfortable with this issue, then  adding ,SUPPRESS(CCN4108)
>   will quite the compiler down.  Of course the parens have to be inside
> double quotes to keep the shell happy, so ccflags in hints/os390.sh
> would become:
>
>     ccflags="$ccflags -W 0,float(ieee),SUPPRESS(CCN4108)"

I wonder if your compiler understands __attribute__.  I think it must, 
but someone who knows Configuration should comment on this and using fgrep.
>
>
>
> *A new error:*
>
> There is a new error that shows up on the first source file
> (perlmini.c), which is in inline.h
>
>     163      return isIDFIRST_lazy_if(p,1);
>
>     ERROR CCN3277 ./inline.h:163   Syntax error: possible missing ')' or
>     ','?
>           6  ERROR CCN3023 ./inline.h:163   Expecting function or
>     pointer to function.
>           7  ERROR CCN3275 ./inline.h:163   Unexpected text ']' encountered.
>           8  ERROR CCN3277 ./inline.h:163   Syntax error: possible
>     missing ')' or ','?
>           9  ERROR CCN3023 ./inline.h:163   Expecting function or
>     pointer to function.
>          10  ERROR CCN3277 ./inline.h:163   Syntax error: possible
>     missing ')' or ','?
>
>     The same general pattern of errors occurs at lines 171, and 185/186
>     of the file.    I compille perlmini.c with the -E flag to generated
>     the proprocessor output. The attached file perlmini.out has result
>     of how line 163 was expanded.
>     /(See attached file: perlmini.out)/
>
>     It looks like the macro expasion split the array  pPL_e2utf across 2
>     lines, and also inserted a couple of parenthesis.  It happened right
>     at offset 2048, so it seems we're hitting another 2K limit, however
>     I'm doing some research to verify this.
>
>     Has this been experienced on any other platforms?

I don't see what that array is included so many times, and will have to 
look at it tomorrow.  That array is not used on other platforms.
>
>
>     John Goodyear
>
>
>
> Karl Williamson wrote on 02/26/2013 04:28:01 PM:
>
>
>  > Subject: New EBCDIC branch available
>  >
>  > I have created a topic branch for work on EBCDIC at
>  > http://perl5.git.perl.org/perl.git/khw/ebcdic
>  >
>  > It is my expectation that this will serve as the on-going repository for
>  > work on this.
>  >
>  > John should build off this.  I believe it fixes a number of problems in
>  > the existing code, and isolates the need for EBCDIC awareness to just a
>  > few code areas.
>  >
>  > I'm pretty sure that the utilities like h2xs would not compile prior to
>  > these patches.
>  >
>  > The next step is to get a successful build of miniperl.  This actually
>  > is fairly early in the build of perl.
>  >
>  > Once that is done, a bunch of things need to be regen'd to know about
>  > the EBCDIC character set, before the make can successfully continue.
>  >
>  > Having an older running perl would help in this process, but I'd like to
>  > figure out and prove-in, and document the steps needed to boot-strap
>  > perl onto a computer without using older infrastructure.
>  >




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About