develooper Front page | perl.perl5.porters | Postings from September 2011

Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT ina future release of Perl

Thread Previous | Thread Next
From:
Karl Williamson
Date:
September 26, 2011 10:07
Subject:
Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT ina future release of Perl
Message ID:
4E80B15F.7050407@khwilliamson.com
On 09/26/2011 10:31 AM, Jesse Luehrs wrote:
> On Mon, Sep 26, 2011 at 06:11:21PM +0200, Jarkko Hietaniemi wrote:
>>>
>>> Executive summary: some current users of the Perl on z/OS need to step
>>> up, and do the porting/support, or it will not happen.
>>
>> I haven't seen the beginning of the discussion: is the plan to
>> remove #ifdef EBCDIC etc. code?  Is it such a maintenance burden?  I
>> thought it was reasonably well contained.
>
> If I've been following properly, the issue actually is that there are
> newer parts of the code that have been added in the past bunch of years
> that don't handle EBCDIC properly, and while we could spend time fixing
> those bugs, if nobody is actually using it, just removing the support
> would be a lot easier.
>
> -doy
>

I've added a lot of code that I've tried to make EBCDIC compatible, but 
without testing, there's no ability to be sure.  I've found a lot of 
existing code that uses hard-coded ASCII platform constants, which 
clearly would fail on EBCDIC; and I've fixed many of those.  But there 
remain others that I know about.  ISTR some time ago finding a missing 
paren in a handy.h macro that would make EBCDIC not compilable at all. 
I have my doubts, never having fully traced it out, that Unicode 
property matches work on EBCDIC.

The bottom line is that I believe no one has compiled Perl on an EBCDIC 
machine for many releases.  So why support it?  The issue isn't so much 
the existing #ifdef's; it is making patches and having to take EBCDIC 
into consideration, which in places can be quite a bit of extra work. 
And it adds extra text to the documentation increasing (unnecessarily 
since no one is using it) the cognitive load on a would-be Perl user, 
and extra work for the Perl documenter.

I thought I had found an EBCDIC smoker a while ago; and the contact 
person there said that he had successfully compiled and run Perl 5.12 (I 
believe) on his machine.  I was very surprised at that, until it came 
out that his shop, while using a platform that was natively EBCDIC, was 
running everything on it in a UTF-8 locale.  They had abandoned EBCDIC 
because IBM had created good UTF-8 support, and there were just too many 
outside programs they wanted to use that didn't run on EBCDIC.

I concluded, perhaps too hastily, that EBCDIC is in rapid decline, 
supplanted by Unicode, and given that this OS (which a quick perusal of 
my email archives didn't find which one it was) allowed modern Perl to 
be run on the IBM hardware.  I don't know which OS's have this ability, 
but I'd guess it would be all of the ones that are still supported.

It seems to me to be a red-herring saying that removing EBCDIC support 
would be risky.

Thread Previous | Thread Next


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