Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-network-addresses-09: (with COMMENT)

[Carsten Bormann <[e-mail]>]

On 4. Oct 2021, at 20:38, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Section 5
> 
>   unused_bits = (-prefix_length_in_bits) & 7;
>   if (length_in_bytes > 0)
>     address_bytes[length_in_bytes - 1] &= (0xFF << unused_bits);
> 
> This looks like it's trying to be C, and the XML agrees.  I think it
> only has the desired effect when two's-complement representation for
> signed integers is used, though (this is not guaranteed by C through at
> least C11, though I have not been closely tracking whether the proposal
> to make C and C++ two's-complement-only has been adopted), and suggest
> reformulating to something like:
> 
>   unused_bits = (8 - (prefix_length_in_bits & 7)) % 8;

Well, I for one don’t like making the “simply” more complicated (*).

In reality, the C family languages have been used exclusively in two’s complement environments for a long time.
C++20 finally made that fact official (**).
(I wouldn’t react as strongly if we hadn't discussed this a while ago for the (pseudo-)code in RFC 8949 [1].)

C itself is lagging (making the same change did not make it into C17 and is scheduled only for C2X [2] [3] [4]).
We could simply say the pseudocode is in C++, maybe using the same text as in RFC 8949 (or, better, pointing to it).

Grüße, Carsten

(*) and, I would at least use % 8 *or* & 7, not one and then the other making the reader wonder if they are different here.
(**) simplifying the specification, but more importantly reducing the immense cost (including security vulnerabilities) from people trying to make their code signed number representation agnostic and in the process getting even the two’s complement case wrong.
[1]: https://www.rfc-editor.org/rfc/rfc8949.html#section-1.2-7
[2]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf
[3]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
[4]: https://en.wikipedia.org/wiki/C2x