From: Christoph Hellwig <hch@infradead.org>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-sparse@vger.kernel.org, linux-xfs@vger.kernel.org,
smatch@vger.kernel.org
Subject: Re: sparse feature request: nocast integer types
Date: Mon, 27 Nov 2023 08:05:00 -0800 [thread overview]
Message-ID: <ZWS+LLCggp70Eav3@infradead.org> (raw)
In-Reply-To: <3423b42d-fc11-4695-89cc-f1e2d625fa90@suswa.mountain>
On Mon, Nov 27, 2023 at 03:51:05PM +0300, Dan Carpenter wrote:
> My plan was to go through the false positives and manually edit out
> stuff like this. The problem is that it's a lot of work and I haven't
> done it. I did a similar thing for tracking user data and that works
> pretty decently these days. So it's doable.
Yes, doing it without specific annotations seems like a pain. I did a
little prototype with the existing sparse __nocast for one xfs type that
is not very heavily used, and it actually worked pretty good.
The major painpoint is that 0 isn't treated special, but with that
fixed the amount of churn is mangable.
The next big thing is our stupid 64-bit divison helpers (do_div & co),
which require helpers to do that case. I'm actually kinda tempted to
propose that we drop 32-bit support for xfs to get rid of that and a
lot of other ugly things because of do_div. That is unless we can
finally agree that the libgcc division helpes might not be great but
good enough that we don't want to inflict do_div on folks unless they
want to optize that case, which would be even better.
Linus, any commens on that?
> I'd prefer an annotation that had the type of the unit built in.
Annotating the type seems really hard. I think the sparse concept
of simply not alowing different of these types to be mixed is good
enough without needing to know the actual unit in the type system.
next prev parent reply other threads:[~2023-11-27 16:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 5:03 sparse feature request: nocast integer types Christoph Hellwig
[not found] ` <CAMHZB6G_TZJ_uQGm5an0-bhG8wCxpEQrUCShen7O61Q9arAf+Q@mail.gmail.com>
2023-11-09 5:30 ` Christoph Hellwig
[not found] ` <CAMHZB6H7Y0m2Y-ZD0PMKiGDeo7_sy=scDrzbBbBuUJfuzLK-Lg@mail.gmail.com>
2023-11-09 5:44 ` Christoph Hellwig
2023-11-09 17:57 ` Linus Torvalds
2023-11-27 12:51 ` Dan Carpenter
2023-11-27 16:05 ` Christoph Hellwig [this message]
2023-11-27 17:26 ` Linus Torvalds
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=ZWS+LLCggp70Eav3@infradead.org \
--to=hch@infradead.org \
--cc=dan.carpenter@linaro.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=smatch@vger.kernel.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