It looks like the compiler codegen is the same between both the old and new code, so this is mainly a question of what makes the code more maintainable. In a C++ codebase I would use decltype within std::numeric_limits<>::max to perform this task, but we don't have that luxury here. If the types of those variables in the state structure were to change, the original code would work without changes, where as your proposed new code would have to be altered. This seems less maintainable to me, since if someone forgets to change those lines, it will silently have the wrong behavior. Is there a specific reason for changing this code? As far as I understand, unsigned types are always represented in memory the same way on all platforms.

I actually think *_max can be removed from the state completely and the constants from limits.h can be used directly instead? I guess I didn't know they existed in C89.

Ah, good point, I should have looked more at where those values where actually used in the code. That seems to be a better solution indeed.

The specific reason is that UNIT_MAX and ULONG_MAX are already defined by the standard library, they're used everywhere in C code, and programmers are used to using these variables.

No real reason, in short :-)

Yes, these global constants could be used instead and uint_max/ulong_max removed from state. I had that in mind, but I thought you might want them to avoid using UINT_MAX - 8/ULONG_MAX - 8 everywhere.

Even with -8 they are still constant, so would be better to store them as const rather than in the state.

Is static const int = ... C89? I'll try...

I've ended up changing to UINT_MAX - 8 and ULONG_MAX - 8 - much simpler and reminds of the - 8.