_Pragma is somewhat standard (an oxymoron if there ever was one!): https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html but I think #pragma/_Pragma convert() is apparently an IBM-ism (EBCDIC-ism?).
Right, on the subtracting 0x30, that was my point: '0' is always '0' but 0x30 is always 0x30. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Monday, November 03, 2014 5:44 PM To: [email protected] Subject: Re: C Language: non-EBCDIC characters in literal strings. On Mon, 3 Nov 2014 17:12:47 -0800, Charles Mills wrote: > >I have seen code that, for example, converted character digits to binary by >subtracting 0x30. Guess what? Does not work for EBCDIC. > It would have been smarter and more likely portable to subtract ('0' - 0). Or to subtract ( 'a' - 'A' ) for an ad-hoc toupper(). >I don't think any language converter should presume that 0x30 really means >0xf0, or that \xa0 means anything other than 0xa0. > I ran into such a problem trying to compile a terminfo source (with "tic") that contained octal escape sequences for ASCII command codes. Worked fine once I translated to EBCDIC by hand. Left me somewhat persuaded that _Pragma convert() or the like should convert '\x30' assuming it means a char, and leave 0x30 alone assuming it means an numeric object. I suspect I'm close to a reason that the POSIX Curses library is not supported in Enhanced ASCII mode. Of course, coders would need to be alert to the distinction. They're not. Cf. Guido van Rossum. How is _Pragma convert() treated by non-IBM compilers? Could it be neutralized with macro definitions? More readily if it were a single token: _Pagma_convert(), so one could: ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
