3 ms·

> If you're pedantic, you could lex (0x41 <= c && c <= 0x5A) 'A' v.s. 0x41 makes no difference for portability. The thing that's unportable about that is that

by avar 8y ago

> If you're pedantic, you could lex (0x41 <= c && c <= 0x5A) 'A' v.s. 0x41 makes no difference for portability. The thing that's unportable about that is that it assumes that the characters A..Z are continuous in your character encoding, which isn't portable C. Although admittedly having to deal with EBCDIC these days is rare in anything except highly portable programs like C compilers or popular script interpreters. This is why ctype.h functions exist. Just use them.

loeg 8y ago
> 'A' v.s. 0x41 makes no difference for portability. The thing that's unportable about that is that it assumes that the characters A..Z are continuous in your character encoding, which isn't portable C. Wait, what? If C does not require A..Z to be contiguous, the distinction between 'A' and 0x41 is extremely significant to portable programs intending to parse ASCII when the native compiler encoding is whatever franken-coding doesn't have contiguous latin characters.
- zozbot123 8y ago
  EBCDIC famously does not have A..Z as contiguous characters, and I wouldn't describe it as a 'franken-coding' just yet - it still finds plenty of use in some places.
  - fork1 8y ago
    Unless you're dealing with mainframes, it's not like you see it everyday.
  - loeg 8y ago
    EBCDIC is a classic example of a franken-coding. If your compiler's source character set is EBCDIC and you want to parse ASCII files, you must use 0x41, etc, instead of 'A'.
- avar 8y ago
  Yes. If the problem was trying to parse ASCII consistently that would be the right solution. My response was to OPs moving the goal post to "portably parsing ASCII" in response to his suggested replacement for a C library function not being portable on non-ASCII systems, which make no sense.
  - jstimpfle 8y ago
    I explicitly wrote "or whatever test" as a comment to the code snippet, and obviously the test was not the point of my comment. Anyway I think most programming languages nowadays have their source encoding specified as UTF-8 or at least something ASCII-like, so ('A' <= c && c <= 'Z') is in fact what I would likely write, and using isalpha() would technically be a bug just as well.

by avar 8y ago

loeg 8y ago

> 'A' v.s. 0x41 makes no difference for portability. The thing that's unportable about that is that it assumes that the characters A..Z are continuous in your character encoding, which isn't portable C. Wait, what? If C does not require A..Z to be contiguous, the distinction between 'A' and 0x41 is extremely significant to portable programs intending to parse ASCII when the native compiler encoding is whatever franken-coding doesn't have contiguous latin characters.

zozbot123 8y ago
EBCDIC famously does not have A..Z as contiguous characters, and I wouldn't describe it as a 'franken-coding' just yet - it still finds plenty of use in some places.
- fork1 8y ago
  Unless you're dealing with mainframes, it's not like you see it everyday.
- loeg 8y ago
  EBCDIC is a classic example of a franken-coding. If your compiler's source character set is EBCDIC and you want to parse ASCII files, you must use 0x41, etc, instead of 'A'.
avar 8y ago
Yes. If the problem was trying to parse ASCII consistently that would be the right solution. My response was to OPs moving the goal post to "portably parsing ASCII" in response to his suggested replacement for a C library function not being portable on non-ASCII systems, which make no sense.
- jstimpfle 8y ago
  I explicitly wrote "or whatever test" as a comment to the code snippet, and obviously the test was not the point of my comment. Anyway I think most programming languages nowadays have their source encoding specified as UTF-8 or at least something ASCII-like, so ('A' <= c && c <= 'Z') is in fact what I would likely write, and using isalpha() would technically be a bug just as well.