Date: Sat, 28 Sep 2019 08:11:24 -0700 From: Conrad Meyer <cem@freebsd.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Dropping the type argument from the mtod macro Message-ID: <CAG6CVpV2j=P6cjDpg46xy2-oZwxjB6hHF61V8m6BNmn1AffXEA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi all, (net@ is BCC'd to keep discussion on arch@.) In the past we've moved away from macros with explicit types as parameters, in favor of casting void* results as needed (e.g., MALLOC()). I'd like to do the same with mtod. The refactoring is easy enough to do safely with a Coccinelle semantic patch. The semantic patch converts instances of "mtod(m, t)" to "(t)mtod(m)". markj@ and rrs@ both point out that the network stack uses the type argument as a visual tool in large functions where the declaration of the lvariable isn't necessarily nearby its use. I think the "(t)mtod(m)" preserves that utility as a visual tool; I may be mistaken. Currently, the semantic patch drops the explicit "(t)" in two limited cases: "t" is "void *", or the "mtod()" invocation is used during initial variable declaration and assignment. The reasoning is that in both cases, the "t" isn't giving you any additional information. Neither of these exceptions is core to the idea, and either could be removed. What do you think? A rough draft of the proposal is sketched out here: https://reviews.freebsd.org/D21669 Best, Conrad P.S., On an earlier version of this revision, markj@ and emaste@ both expressed concern for downstream consumers. There are two aspects of the current differential that should smooth that experience. First, a backwards-compatible two-argument mtod(m, t) is retained using an ugly macro hack. (Existing code compiles without modification.) Second, the coccinelle semantic patch will be checked in to the tree somewhere for use by downstream consumers that want to convert their code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpV2j=P6cjDpg46xy2-oZwxjB6hHF61V8m6BNmn1AffXEA>