Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp600438pxf; Wed, 7 Apr 2021 07:19:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwesg8Ox5Vos4/mxHftNipla5oXfnRmtjEtskYYmMwXLq+4mXKLxwhsP0WKK7K/cCzKzKSF X-Received: by 2002:a05:6402:2208:: with SMTP id cq8mr4725756edb.122.1617805193596; Wed, 07 Apr 2021 07:19:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617805193; cv=none; d=google.com; s=arc-20160816; b=bPlnhyWy41ar3Hqhw4216H3j23EIZ5Y0/UwtCNsZ/LbA2xcCApdayKyYPrlg0QJFrc CV/BYKd+HtbFwO5fEso3KTBtObltsbkY89hWFE1Ts09Gjwa/a3qTB3L5Lsa0A9H9l7Ih B/cV5oqHvlEtGfjLzl5rkTC12rebbZmSkv2uVEtuf+ax73wl8jZ0oYGpOGTzaBCjoEf7 3U78cDuwWjn0IJjQoHw665t6tclyBkTLHvf73lS0u8qBQSW76EwPpEZO78stJ9+GBL4l JWS96bCSQMlJX1+W0+mUY2rup2ZlYfJ8U2G62yJ/4M5DpRwz+yOekS33Jxhkj86MXixP V6HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=7xsAv8A6OydOCAEZA5I/WU89mz+dZyrsY8jU0WCiVvw=; b=iy6Udu9RE/s799hV+7BdP6oKUTGphOM1x4KOzPt9U+olaJcnrJLtUuHtXJIx+knhA2 zw3VrsURmkN7hjWJA5MN9YzAltj8IPJQlJCx2jEo4ENebbfjooBh2/cD6exZ/qK0ABTl eSOm52bNLNe93VT6uDYveBPJNky1h2/mdKxHgHFQgXxLwY7JM6uj4BVDvMgg6OyJv+mY Yo8moVFyIDpouDc5lzhX0vNIh0fe3x3+Tk8R+WVEOvJqIe1N/Qv8crzJFMvK8WXJR7Za I1g07emLFT9gzuW+FNEQ4SxyqPPYW8XpK5shEMWI9DmojAGxDGKhPlVTIYIO4Y4DGYiI xEKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 23si948150ejx.233.2021.04.07.07.19.29; Wed, 07 Apr 2021 07:19:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234174AbhDGD0h (ORCPT + 99 others); Tue, 6 Apr 2021 23:26:37 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:51542 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233915AbhDGD0h (ORCPT ); Tue, 6 Apr 2021 23:26:37 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01424;MF=tianjia.zhang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0UUky-cb_1617765985; Received: from B-455UMD6M-2027.local(mailfrom:tianjia.zhang@linux.alibaba.com fp:SMTPD_---0UUky-cb_1617765985) by smtp.aliyun-inc.com(127.0.0.1); Wed, 07 Apr 2021 11:26:25 +0800 Subject: Re: [PATCH] crypto: sm3 - use the more precise type u32 instead of unsigned int To: Gilad Ben-Yossef , Ard Biesheuvel Cc: Herbert Xu , "David S. Miller" , Eric Biggers , Mimi Zohar , Linux Crypto Mailing List , Linux kernel mailing list , Jia Zhang References: <20210326022128.71727-1-tianjia.zhang@linux.alibaba.com> From: Tianjia Zhang Message-ID: <5a5028e1-7cb2-701c-ce0f-1bb9f79cb83d@linux.alibaba.com> Date: Wed, 7 Apr 2021 11:26:25 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 3/26/21 5:38 PM, Gilad Ben-Yossef wrote: > Hi, > > Thank you for the patch! > > On Fri, Mar 26, 2021 at 5:21 AM Tianjia Zhang > wrote: >> >> In the process of calculating the hash, use the more accurate type >> 'u32' instead of the original 'unsigned int' to avoid ambiguity. > > I don't think there is any ambiguity here, as both forms are always > the same size. > > Generally, I tend to use the convention of using 'u32' as denoting > variables where the size is meaningful - e.g. mathematical operations > that are defined in the standard on 32 bit buffers, versus using > plain 'int' types where it isn't - e.g. loop counters etc. > > Having said that, even under my own definition possibly the w and wt > arrays in sm3_trandform() should be changed to u32. > I don't object to changing those if it bugs you :-) > > Cheers, > Gilad > > Thanks for your opinions. This is just to make the form more uniform. This is not a mistake. If it is not necessary, just ignore this modification. Best regards, Tianjia