On Fri, 10 Aug 2018 16:38:26 -0400, Thomas David Rivers wrote:
>>
>#pragma codepage presents its on set of problems.
>
>Consider, for instance, you move the source into a Git repository
>on a remote (and ASCII) system. And, if you have a cross-compiler,
>might consider compiling on that remote system.
>
>Now, your source claims to be in code-page 1047 - but it certainly isn't likely
>to be so, since the move to the ASCII system rendered it in ASCII.
>
>This means your cross-compiler has to quietly ignore the #pragma codepage
>and hope that your transmission to the ASCII system did "the right thing."
>
Does FTP or another transport vehicle by defaut set SBDATACONN to the
tagged character set?
This is a general problem with self-defining data[1]. If someone sends me
email from an ASCII system with "Content-type: text/plain; charset=ISO8859-1",
it arrives in my VM inbox obviously translated to a variant (there are several)
of EBCDIC, with the MIME header still saying (however in EBCDIC) "ISO8859-1".
Shouldn't it be converted to reflect the translation?
If I "pax" an EBCDIC file tagged with separator=NL and request conversion
to ASCII, pax correctly tags the file with the target charset, converts the
NLs to LFs, but still leaves "separator=NL". SR. WAD.
Converting self-defining data should adjust the metadata.
>Trigraphs are hideously ugly; but they did produce portable source files
>that could be moved around and compiled.
>
>As I mentioned in another post; C++17 removed support for Trigraphs
>from their language definition.... so, they are generally going away...
I hate EBCDIC!
[1] "What's self-defining data?"
"I dunno. Why don't you ask it!?"
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
