Is it portable to cast an unsigned value to its signed version to prevent underflow?

Would casting a to a (signed) int do the trick?

Yes, this would be the way to handle this. Since the cast doesn't result in a change of value, the result is well defined.

This is spelled out in section 6.3.1.3p1 of the C23 draft standard regarding integer conversions:

When a value with integer type is converted to another integer type other than bool, if the value can be represented by the new type, it is unchanged

So if you do this:

int b = (int)a - 128;

The unsigned int value of 64 stored in a will be converted to an int value of 64. Then the subtraction will happen with both sides having type int resulting in an int value of -64 which subsequently is assigned to b.

How do I avoid this implementation-defined behaviour?

You do just that. Not a "trick" like casting a to a signed int. As @dbush notes, that will work, but - you should do your arithmetic in a type whose range of representation is large enough to hold whatever values you work with, instead of having to remember to perform "tricks". Moreover - if you're mixing int's and unsigned's, and performing arithmetic on unsigned's that is not carefully-controlled - that is somewhat suspicious. Should it really be happening? should you not have just been using signed ints in the first place? Quite possibly. Don't use unsigned for the gain of an extra bit.

_{Caveat: If youre in a performance-critical tight loop, then my advice is less valid. In that case, you might need to accept non-portable behavior and split your implementation based on which platform your on (e.g. with preprocessor directives, or templating on types or values which are platform dependent etc.) And you want to minimize costly per-element casts. But of course, in such cases you might not even want to use types as large as int and unsigned in the first place. It all depends}