Re: [Perl/perl5] Fix z/OS EBCDIC for 5.44 (PR #24432)

On 6/1/26 08:21, Aristotle Pagaltzis wrote:

> 
> Can you get |io/socket.t| to pass, as well? Would that make us pass 
> tests on z/OS? And… would that then be a smaller change than what’s left 
> over from this PR?
> 

The problem is that z/OS is a bigendian machine, and when you pass a 
larger than needed buffer size to getsockopt(), the result is 
right-justified and in the wrong position.  The POSIX standard says only 
that the size passed in has to be sufficiently large to hold the value. 
So z/OS has a restriction not shared by other systems.  @mauke showed on 
IRC how the implementation of the function could easily work properly, 
but it doesn't.

Thus, on this platform, the passed buffer size needs to be the exact 
required size,  On z/OS all but one supported option type is an int.

By adding these lines to the appropriate place in pp_sys.c, getsockopt() 
works, and io/socket.t passes

2937a2938,2945
  > #ifdef OEMVS
  >         if (optname == SO_LINGER) {
  >             len = sizeof(struct linger);
  >         }
  >         else {
  >             len = sizeof(int);
  >         }
  > #else
            len = SvCUR(sv);
  2938a2947
  > #endif


Notice that there is no change to the generated object for any platform 
but z/OS.

With that change, and further changes to README.os390 and 
hints/os390.sh, all tests pass on a static build, except for false 
positives that README.os390 would say to ignore.

However, I started testing on other build types, and there are a couple 
failures on these.

1) On DEBUGGING builds, there is a bug in utf8.c when converting the 
UTF-8 of a Unicode non-character code point to its ordinal value, when 
those are disallowed or warned about, and the input is malformed by not 
having enough bytes available to fully specify the character.  It leads 
to an assertion failure.  This is a very edge case tested by XS-APItest 
and very unlikely to occur in real life.  The bug existed in 5.42, so is 
not a regression.  If not for the assertion failure, the code does the 
right thing.

2) A dynamic build won't compile without a patch that IBM has furnished 
to Makefile.SH.  With those changes, all related tests that were 
previously skipped now pass except for one test in 
ExtUtils-MakeMaker/t/02-xsdynamic.t.  I think, however, it is an 
important test.

So, here's what I think should happen for 5.44

It is a no-brainer to accept a patch to README.os390 updating its 
instructions to accurately describe the current conditions.

Similarly, hints/os390.sh should be patched.  I made two mistakes in 
b46576204b7085570170e93270681486d5fe6d50.  One of these led to an 
infinite loop in Configure continuously forking and running out of 
processes.  The other mistake is inconsequential.  Since, then, I have 
extensively cleaned it up.  Again a patch to this can't affect any other 
box.

If we want to say that core perl works completely as far as we know on 
z/OS non-DEBUGGING static builds, then apply the above patch to 
pp_sys.c.  Again it won't affect any other platform.  I somewhat favor 
doing this, as this would be the first time in probably 20+ years that 
we could make that claim.  (And actually, there were unexplained 
SEGFAULTs back then, that I have since figured out and fixed.)

If we choose to do that and want to say that core perl also works 
completely as far as we know on static DEBUGGING builds, then patch 
utf8.c to #ifdef out the assertion.  That isn't the ultimate fix, which 
is pretty trivial, but this patch would not affect any other platform.

If we want to get dynamic builds to work, we would need to patch 
Makefile.SH, and possibly ExtUtils-MakeMaker/lib/ExtUtils/MM_OS390.pm. 
The patch that IBM has furnished works, except for that failing test, 
but it looks to me like it could be done more elegantly by someone who 
understands this area better than IBM or I do.  I think it would take 
just a few minutes, may a half hour of such a person's time to figure 
out something.