Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH bpf-next v2 0/5] cleanup for data casting
To:     Pu Lehui <pulehui@huawei.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc:     bpf <bpf@vger.kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
References: <20220718132938.1031864-1-pulehui@huawei.com>
 <CAADnVQJQ_WU6wfyaAkk3f9DaawDtsDT4BLZeBp2aPEZ4TMaYVQ@mail.gmail.com>
 <b5c03458-7fd8-3739-63b1-11618f4b8a6a@huawei.com>
From:   Edward Cree <ecree.xilinx@gmail.com>
Message-ID: <df76c412-d9e4-b89d-1bd3-eefb50280f57@gmail.com>
Date:   Tue, 19 Jul 2022 14:48:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <b5c03458-7fd8-3739-63b1-11618f4b8a6a@huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Precedence: bulk

>> On Mon, Jul 18, 2022 at 5:59 AM Pu Lehui <pulehui@huawei.com> wrote:
>>> Previously, we found that memory address casting in libbpf
>>> was not appropriate [0]. Memory addresses are conceptually
>>> unsigned, (unsigned long) casting makes more sense. With the
>>> suggestion of Daniel, we applied this cleanup to the entire
>>> bpf, and there is no functional change.
Fwiw, pointers in C aren't necessarily unsigned; some versions of
 gcc have treated them as signed and — if no object can straddle
 the sign boundary — it's even allowed by the standard. [1]
(And at a hardware level, a memory address is just a pattern of
 bits on an address bus, which isn't arithmetic at all.)

-ed

[1]: https://yarchive.net/comp/linux/signed_pointers.html