Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03

Joerg Ott <ott@in.tum.de> Thu, 07 May 2020 07:34 UTC

Return-Path: <ott@in.tum.de>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405413A0982; Thu, 7 May 2020 00:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 yqnYxm0EAxeN; Thu, 7 May 2020 00:34:42 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F1F3A07B3; Thu, 7 May 2020 00:34:40 -0700 (PDT)
Received: by mail.in.tum.de (Postfix, from userid 107) id 790BD1C084D; Thu, 7 May 2020 09:34:38 +0200 (CEST)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 3CAA41C084C; Thu, 7 May 2020 09:34:36 +0200 (CEST) (Extended-Queue-bit tech_loxsz@fff.in.tum.de)
To: Rob Austein <sra@hactrn.net>, Randy Bush <randy@psg.com>
Cc: tsv-art@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org
References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <m2sggclma3.wl-randy@psg.com> <20200506234103.8BB3C2014E48DE@minas-ithil.hactrn.net>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <2329fb70-321a-2192-6346-2d3c8146c45b@in.tum.de>
Date: Thu, 7 May 2020 09:34:35 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200506234103.8BB3C2014E48DE@minas-ithil.hactrn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/8Wx0qc5w09DR7BkU9DU4EZ1Vu_w>
Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 07:34:45 -0000

On 07.05.20 01:41, Rob Austein wrote:
> On Wed, 06 May 2020 18:40:52 -0400, Randy Bush wrote:
>>
>>> I also assume that the pseudo code on p.11 would benefit from a leader
>>> '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might
>>> fill the high order bits with '1's, which is clearly not intended.
>>
>> ok, but what kinky compiler are you using?  :)
>>
>>       result = (result >> 32) + (result & 0x0FFFFFFFF);
>>       result = (result >> 32) + (result & 0x0FFFFFFFF);
> 
> Last I checked, the pedantic C syntax would be 0xFFFFFFFFU.
> But pseudo-code means whatever we define it to mean :)
> 

Just leave it as is.

If my dim memory on this serves me somewhat well, the issue arose with
different compilers at some time in the past.  Just checked and it seems
fine for XCode now.  I came across this multiple times, which is
probably why it stuck.

Jörg