fork

What I like about ctype functions accepting int is that it's not possible to make them accept Unicode code points without breaking compliance because despite of accepting int, the value still has to be representable with 8 bits.

Hobovsky is right; the Linux manpage for ctype.h functions gives more details:

The standards require that the argument c for these functions is either EOF or a value that is representable in the type unsigned char; otherwise, the behavior is undefined.

If the argument c is of type char, it must be cast to unsigned char ... This is necessary because char may be the equivalent of signed char, in which case a byte where the top bit is set would be sign-extended when converting to int, yielding a value that is outside the range of unsigned char.

I think the reason behind this might be purely historical: these functions were implemented as O(1) lookup tables indexed by the value of c. This worked well for 7-bit ASCII, but if a negative value is passed this would access the lookup table out-of-bounds.

The negative chars are not a remote possibility either: this will happen if you use modern UTF-8 encoded strings on a platform where char is signed (which is pretty much all of them by default).

The <ctype.h> functions are problematic for several reasons: they depend on the locale, they are inadapted to modern Unicode where "characters" span more than one byte, the is___() predicates do not return a bool, the cast to (unsigned char) is necessary if one wants to write clean code. But I use them on Codewars because I like to use builtins and I know that on Codewars they will always work the way I expect them to.

That's because cctype functions do not work well with characters represented with negative values. cctype functions accept int equivalent of one character as parameter, and if on a given platform char is signed, then characters above 0x7F end up being passed as a negative int, which might be not what such function expects.

It makes sense, because \ is misleading when presented in assertion messages.

hey, thanks for the review :)

there was a bug in the if (): len_act != len_in --> len_act != len_exp. fixed.

fixed

Rejecting as issue has already been resolved

it's hard to remember all the symbols that are in the global namespace when you name things. in this particular case, not only it does not affect the user's code, but input() would never be used on Codewars anyways. But fine, renamed to inpt

done here

Not in this kata.

Fixed by fork above

Superceded by latest fork :(