It is unclear whether the CF flag is read. Intel Docs Guide says:
If the result of an arithmetic operation is treated as an unsigned integer, the CF flag indicates an out-of-range condition
The negation of something that is treated as unsigned is clearly invalid, since without a sign value its sign has turned upside down and will still remain unsigned (if it is not equal to zero). Therefore, using the pencil and paper method, you get completely opposite results: "pencil carry = 1" when negating zero and "pencil carry = 0" when negating any other bit diagram.
This is probably why we have the flag carry FLAG 'in the flag register, and NOT' carry BIT '. And again, the carry flag is there to indicate that the result of the operation on the operand (s) (treated as unsigned) is out of the allowable "unsigned range" for a certain number of bits.
If the value you deny is treated as signed, you should see the overflow flag.
The key point here is : "carry FLAG" is not "carry BIT". Sometimes it is bahavas, but not always.
BTW: It's not that only x86 / 64 does this. This is the same, for example, in AVR Atmel.
ARM is likely to do the same, as their manuals state that:
For a subtraction, including the comparison instruction CMP and the negate instructions NEGS and NGCS, C is set to 0 if the subtraction produced a borrow (that is, an unsigned underflow), and to 1 otherwise.
and in general, ARM doc call Carry Flag is the Carry / loan flag , so it should not be considered as Carry BIT