Is a character literal ('A') exactly equivalent to a hex literal (0x41)

Question

Is there any situation in which changing 'A' to 0x41 could change the behaviour of my program? How about changing 0x41 to 'A'? Are there any uncommon architectures or obscure compiler settings or weird macros that might make those to be not exactly equivalent? If they are exactly equivalent in a standards compliant compiler, has anyone come across a buggy or non-standard compiler where they are not the same?

Answer 1

Is there any situation in which changing 'A' to 0x41 could change the behaviour of my program?

Yes, in EBCDIC character set 'A' value is not 0x41 but 0xC1.

C does not require ASCII character set.

(C99, 5.2.1p1) "The values of the members of the execution character set are implementation-defined."

Answer 2

Both the character literal 'A' and the integer literal 0x41 have type int. Therefore, the only situation where they are not exactly the same is when the basic execution character set is not ASCII-based, in which case 'A' may have some other value. The only non-ASCII basic execution character set you are ever likely to encounter is EBCDIC, in which 'A' == 0xC1.

The C standard does guarantee that, whatever their actual values might be, the character literals '0' through '9' will be consecutive and in increasing numerical order, i.e. if i is an integer between 0 and 9 inclusive, '0' + i will be the character for the decimal representation of that integer. 'A' through 'Z' and 'a' through 'z' are required to be in increasing alphabetical order, but not to be consecutive, and indeed they are not consecutive in EBCDIC. (The standardese was tailored precisely to permit both ASCII and EBCDIC as-is.) You can get away with coding hexadecimal digits A through F with 'A' + i (or 'a' + i), because those are consecutive in both ASCII and EBCDIC, but it is technically something you are getting away with rather than something guaranteed.