Catching the mismatch

Posted Feb 11, 2025 11:24 UTC (Tue) by q3cpma (subscriber, #120859)
In reply to: Catching the mismatch by farnz
Parent article: Maintainer opinions on Rust-for-Linux

Does it matter much? Such a real world case shouldn't happen often. Also, a very common way of achieving the same result (we use that in our C++ code base to please clang-tidy and co.) is to comment the parameter name, like so: `bool f(int* a, int* /*b*/)`

Catching the mismatch

Posted Feb 11, 2025 11:41 UTC (Tue) by farnz (subscriber, #17727) [Link]

It makes a huge difference to the usability of the warning. Ideally, you want your codebase to be warning-free after each reviewed patch is applied[1], so you want to be able to quickly suppress an unused variable warning when it's only going to exist until the next patch in the series is applied. You also want the name to stay around, so that if the code is usable as-is, with only part of the series applied, anyone using it has a clue about what value to fill in.

That leads to you wanting a simple and obvious way to suppress the warning when you're not yet using a parameter, and yet to still give it a name. The alternative (and what most C and C++ codebases I've seen do) is to simply not bother enabling the warning at all, because it's too noisy.

[1] First, you want the codebase to be warning free because that means that a new warning appearing is something to fix; you want warnings to tell you that something is wrong with the codebase, and not to be something that you routinely ignore because they're meaningless. Second, you want maintainers to be able to say "patches 1 through 5 are applied, but I don't like the way you frobnicate your filament in patch 6, so please redo patches 6 onwards with the following advice in mind". And third, if I see a function bool do_useful_thing(int *operations_table, int index, bit_mask), it's hard to work out what the last parameter will mean later. If I see bool do_useful_thing(int *operations_table, int index, bit_mask _ignored_cpus_mask), it's obvious that that last parameter will be an ignored CPUs bitmask when ignoring CPUs is implemented later.

Catching the mismatch

Posted Feb 11, 2025 13:05 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Does it matter much? Such a real world case shouldn't happen often.

When I was programming in C regularly, it happened a lot, and it was a pain in the arse - the warnings swamped everything else.

As soon as you start using callbacks, passing functions to libraries, what have you (and it's libraries that are the problem, where the generic case needs the parameter but your case doesn't), you want to be able to say "I know this variable isn't used, it's there for a reason".

This was Microsoft C6 with warning level 4, and I just couldn't find a way to suppress a warning - everything I tried might suppress the warning I was trying to get rid of, but just triggered a different warning instead.

Fortunately, it was me that set the rules about errors, warnings etc, so the rule basically said "all warnings must be fixed or explained away".

Cheers,
Wol