Hacker News Reader

Comment by joker3 | Hacker News Reader

Why do we need to be able to add two characters again?

  char toupper(char c) {
    if (c >= 'a' && c <= 'z') {
      return (c - 'a') + 'A';
    else { return c; }
  }

It's worth mentioning explicitly that while `c - 'a'` is the more obvious application of character addition in your example, `c >= 'a'` is another one that's even more common. Pretty much everyone immediately understands that we want to be able to sort characters.

Yeah- but the problem of poorly-defined result type isn't present for comparison operators, since a bool is a b... oh, hold on, C. Since an int is an int. Sigh.

In C, 'a' is an int so most of those are not char/char operations.

In C++, 'a' is a char and the comparison result is a bool, though it doesn't really make a difference in that function.

When you're sorting, you're generally comparing two variables to each other, as opposed to comparing one variable to a literal constant.

The Erlang is Perlilous:

  toUpper(char) -> $ + char.   % It's "$ "

You showed an example of subtracting a character from another. The GP asked for an example of adding two characters.

  (c - 'a') + 'A'

contains both

I thought about saying

   (c + 'A') - 'a'

to make this more clear, but I think that's actually UB with signed chars- e.g. for c='a', 'a'+'A' exceeds the range of a signed 8-bit value!

Promotion should save us here, but that's a bit too yikes-y for my comfort.

It does not. Subtracting a char from a char involves usual arithmetic conversions as well and the result is typically an int. Next, you have addition between an int and a char.

That relationship is valid for ASCII, and for character sets derived from ASCII, but it's not guaranteed by the language. In particular, in EBCDIC the alphabet is non-contiguous.

Absolutely- this code only works with ASCII-ish charsets.

Adding two characters isn't strictly needed for that -- you're relying on the assumption that (c - 'a') is of type character, but it's actually the offset between two characters. The rules for those two types would be:

char + char = invalid

char + offset = offset + char = char

offset + offset = offset

char - char = offset

char - offset = char

offset - char = invalid

offset - offset = offset

Given that, (c - 'a') + 'A' is perfectly valid without adding two characters.

edit: formatting

That's a good question, now that we have [u]int8_t, [u]int16_t, etc. for explicit bitness values. (Although both can have more than specified number of bits on some platforms.)

But `uint16_t + uint16_t` has exactly the same problem -- if it's a typedef for `unsigned short`, there will be promotion to either `int` or `unsigned int`.

A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int, which is undefined behavior! So "unsigned types wrap around" doesn't apply to `uintN_t`, because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic.

Of course, in practice this just means: every C and C++ program relies on tons of implementation-defined behavior. A `sizeof(int)` greater than 32-bits would break most code in existence (e.g. hash code computations using `uint32_t`).

> A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int

Last time similar thing bit me was when the platform had 16-bit int... so just adding two int16_t can very well cause int overflow.

> because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic

You can deduce the width (number of sign + value bits) of the standard integer types from their limits (e.g. INT_MAX, INT_MIN, etc). The problem has been that this is non-trivial if not impossible to do from the preprocessor. The next C standard will include width constants (e.g. INT_WIDTH) for the standard integer types.

In practice programs on these weird large-int machines would just use `-fwrapv` and move on.

No, uint8_t is guaranteed to be exactly 8 bits wide (unlike uint_fast8_t or uint_least8_t).

String forming.

How would you form strings by adding 'char' type values together? This is not about concatenation operation, we're talking about C/C++. They do not have syntactic sugar concat for chars.

(In C++, you of course have operator overloading, that's how std::string concat sugar works.)

'1' + '1' == 'b'. Because 49 + 49 == 98. ASCII '1' == 49, and 'b' == 98.

Reply on news.ycombinator.com