I think strlen is called tons of times.

Merged, thanks!

fork

In C, failure message is not helpful.

The expression (digits(n - 1)) == (i) is false.

Fixed

Merged, thanks!

Thank you both for the detailed explanation!

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.

if (isalpha((unsigned char)*string))

Why casting to unsigned char?

- nonAlpha[] = "0123456789_ !@#$%^&*_(),.?|{}[]-=+\\/";
+ static const char symbols[] = "0123456789_ !@#$%^&*_(),.?|{}[]-=+/";

Removing \ from tests?

Reopen scarecrw's issue below, since the JavaScript version still tests non-existing frets.

For example: note=F#, exact=true, string=3, position=2 where the 3rd string only contains a single F#. It should either be mentioned in the description that these "hypothetical positions" are tested, or just removed from the test cases.

.