From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Owen Hilyard" <ohilyard@iol.unh.edu>
Cc: "Aaron Conole" <aconole@redhat.com>,
"David Marchand" <david.marchand@redhat.com>,
"dev" <dev@dpdk.org>,
"Stephen Hemminger" <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] Define statement with UB prevents compilation using UBSAN
Date: Fri, 11 Jun 2021 11:19:03 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C6183D@smartserver.smartshare.dk> (raw)
In-Reply-To: <20210610143604.48278bcc@hermes.local>
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Thursday, 10 June 2021 23.36
>
> On Thu, 10 Jun 2021 16:51:37 -0400
> Owen Hilyard <ohilyard@iol.unh.edu> wrote:
>
> > Working backward to the define
> > statement, AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY is defined
> as
> >
> > #define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1 << 31)
>
> Why not (1u << 31)?
Yes, this is better. You want the type of the defined constant to be uint32_t.
It can also be defined in hexadecimal form as (0x1u << 31), or (0b1u << 31) in binary form.
<rant>
On the CPUs/compilers supported by DPDK, the exact type of an unsigned integer is uint32_t. If the CPU/compiler used 64 bits for integers, you would need additional type casting to get it down from 64 to 32 bits.
If we were to be really pedantic, the other defined constants that fit in a signed integer, e.g. (1 << 30) should also be defined as (1u << 30) if they are supposed to be unsigned integers. However, not many people worry about signedness when writing code, especially if an unsigned value fits into a signed variable or constant.
</rant>
Thank you for your effort on this, Owen. Keep up the good work! :-)
next prev parent reply other threads:[~2021-06-11 9:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 20:51 Owen Hilyard
2021-06-10 21:36 ` Stephen Hemminger
2021-06-11 9:19 ` Morten Brørup [this message]
2021-06-11 14:34 ` Aaron Conole
2021-06-11 18:15 ` Owen Hilyard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35C6183D@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=aconole@redhat.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ohilyard@iol.unh.edu \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).