The Fix Wasn't Easy, or C Precedence Bites

The precedence stuff here is pretty basic. When in doubt, using parentheses to make order explicit is never wrong. Or consult https://en.cppreference.com/w/c/language/operator_precedence... .

The code gets ridiculously easier to read if you write src[0] and src[1] instead of (*src) and (*(src+1)). And, as a bonus, the precedence problem disappears.

I really don't understand people why write C code like the original code. It's just asking for a bug.

Making the first thing a block doesn't add any lines and makes it less brittle, and makes future diffs better

And they do some weird alignment of assignments, and for some reason carry on adding extra spaces for some assignments even when they're alone in a block?

And they go out of their way to do pointer arithmetic rather than array operations that are more readable

And the code is essentially sscanf(str, "%%%2x", &value) plus some checks, so why not write that instead?

Also what kind of psycho uses CppStyleFunctionNames() in C?

One that has gotten me more than once in Python (I really don’t code Python that much) is “1 + 2 if True else 3”. I keep thinking the parenthesis are “1 + (2 if True else 3)”, but it’s actually (1 + 2). Or am I lying to you and it’s the other way around?! I don’t know, why don’t you go check the Python interpreter :)

The function has undefined behavior if given any value that is not in the range 0 to UCHAR_MAX, or the value EOF.

Some implementations are robust in the face of the values -128 to -1 but ISO C doesn't require that.