On 03/29/2017 03:29 PM, Dick Franks wrote:
On 29 March 2017 at 21:18, karl williamson via RT <perlbug-follo...@perl.org <mailto:perlbug-follo...@perl.org>> wrote: I'm willing to look at your code for obvious EBCDIC issues if you want to post it or email it to me. Thanks for showing an interest. However, there is no substitute for running tests in a real EBCDIC environment. Proof of the pudding is in the eating, not reading the recipe. If you know anyone with some real kit, please encourage them to get in touch. Regards --Dick
If anyone with real hardware is willing to help you, they will be on the mvs list, and can respond. Such hardware is hard to come by, and tends to not be directly connected to the internet, so testing DNS things might not be feasible.
The ticket was closed because this is not a perl bug, but a request for assistance, which has been redirected to the appropriate channel.
I could have likely quickly told you if the code was on the right track to be EBCDIC compatible. Properly written Perl and XS code should rarely need to have separate paths for the two character sets. (There are only a few in all of the Perl core.) If your code had such paths, that part is probably wrong, and should be thrown away. Documentation is in perlebcdic and perlhacktips (the latter for XS code and .t tests). See also the documentation for the utf8 module which gives functions that can be used to portably specify any character. (These functions aren't related to utf8, and were placed in this module for convenience, where they remain).
The most typical failures are in .t files. A lot of tests tend to be written expecting a particular bit pattern result related to character sets, and these will show as failures, even if the module actually works. perlhacktips gives suggestions for writing portable tests.
