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

Carsten Bormann <cabo@tzi.org> Tue, 05 October 2021 20:38 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916CB3A0D23; Tue, 5 Oct 2021 13:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qXNmStWrtqM; Tue, 5 Oct 2021 13:38:22 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DD23A0D20; Tue, 5 Oct 2021 13:38:21 -0700 (PDT)
Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HP8YQ53lMz2xNq; Tue, 5 Oct 2021 22:38:18 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <163337270139.24096.2858053457546637595@ietfa.amsl.com>
Date: Tue, 5 Oct 2021 22:38:18 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-cbor-network-addresses@ietf.org, Barry Leiba <barryleiba@computer.org>, cbor-chairs@ietf.org, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <54845F41-869A-43CE-BF02-825CB728A2CA@tzi.org>
References: <163337270139.24096.2858053457546637595@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/01PLiiTDG7t29sshG8pUFP-cieY>
Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-network-addresses-09: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2021 20:38:29 -0000

On 4. Oct 2021, at 20:38, Benjamin Kaduk via Datatracker <noreply@ietf.org> 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