Is -(uintN_t)x or unsigned inverse in other words guaranteed to work in two's complement by the C standards?

Summary

-(uintNt)x, (v & -v), and v & (~v+1) are not safe. Sample cases proving that are below.

v & - (uintmaxt) v is safe.

Details

From the title of the question:

… -(uintNt)x …

Consider x = 1, a uint16t cast, and a C implementation that uses a 32-bit one’s complement int. The desired result is the 32-bit two’s complement of 1, which is 11111111 11111111 11111111 11111111₂. In this situation, 1 will be converted to uint16t, which does not change the value, yielding 1. Then this uint16t value is promoted to int, again yielding 1. Then this int is negated. Since int is one’s complement, the result is 11111111 11111111 11111111 11111110₂, which is not the desired result.

From the body of the question:

… (v & -v) …

Consider v = 1 and a C implementation that uses a 32-bit one’s complement int. The desired result here is that -v produce the two’s complement, 11111111 11111111 11111111 11111111₂ and v & -v produce 1. In this situation, for -v, 1 will be negated in the one’s complement int, producing 11111111 11111111 11111111 11111110₂. Then the & will produce 0, which is not the desired result.

So the answer is no, neither of these code fragments is guaranteed to work as desired by the C 1999 standard.

C 2024 added a requirement that two’s complement be used (in clause 6.2.6.2), so the above two fragments would work in C 2024.

Also from the question:

If it's not guaranteed that two's complement arithmetic is used for unsigned inverse, what about v & (~v+1)?

This will work if the value of v is not too large in magnitude. However, it can fail even in two’s complement if v is large. Consider a C implementation with 32-bit two’s complement int and v = − 2³¹ = 10000000 00000000 00000000 00000000₂. Then ~v produces 01111111 11111111 11111111 11111111₂. This the the maximum int value, 2³¹−1. Then ~v+1 overflows, and the behavior is not defined by the C standard. However, this is safe as long as v is an unsigned type, since then it is either narrower than int and cannot produce a troublesome value or it so wide it will not be promoted to int.

Another problem case with v & (~v+1) is that ~v may produce a trap representation (essentially a bit pattern that is reserved to indicate it is not a value in the type). Then adding 1 to this trap representation would have undefined behavior. The trap representation would be 10000000 00000000 00000000 00000000₂ in sign-and-magnitude or two’s complement and 11111111 11111111 11111111 11111111₂ in one’s complement. The former can be produced from ~v when v has the unsigned int value 01111111 11111111 11111111 11111111₂, and the latter can be produced from 0, so v & (~v+1) is not always safe even when v has an unsigned type.

v & - (uintmax_t) v would work in C 1999, since then the negation would be done in an unsigned type that cannot be promoted to a signed type. A good compiler might optimize this to code that uses a smaller type when sufficient (especially if it is immediately converted to a narrower type).