Re: [PATCH 1/3] lib: zstd: Fix unused variable warning

[Nick Terrell]

> On Nov 17, 2021, at 8:45 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Tue, Nov 16, 2021 at 5:43 PM Nick Terrell <nickrterrell@xxxxxxxxx> wrote:
>> 
>> From: Nick Terrell <terrelln@xxxxxx>
>> 
>> Backport the fix from upstream PR #2838 [0]. Found by the Kernel test
>> robot in [1].
> 
> Ugh. Mind having a better commit message?
> 
> This just tells you that it's a backport. It doesn't actually talk
> about what it fixes.
>
> Yes, the summary line says "Fix unused variable warning", but it
> doesn't talk about why that variable is unused and why it's not
> removed entirely.
> 
> And it's not obvious in the diff either, because the context isn't
> sufficiently large.
> 
> So a comment along the lines of "the variable is only used by an
> 'assert()', so when asserts are disabled the compiler sees no use at
> all" or similar would be appreciated.

Yeah of course, thanks for the review! I’ll put up a fix shortly.

> Of course, the alternative would be to make the backup definition of
> 'assert()' actually evaluate the argument. That's not what the
> standard assert() is supposed to do, but whatever, and the zstd use
> doesn't care.
> 
> So using
> 
>    #define assert(condition) ((void)(condition))
> 
> instead would also fix the warning at least in kernel use (but not
> necessarily outside the kernel - the standard C 'assert.h' is just
> evil).

I totally agree that the standard C assert is not ideal, however I’d
be hesitant to do that in a quick fix. Just because zstd assumes
that asserts are removed from production builds, so there are at
least a few places where it makes potentially expensive function
calls.

I may be able to try something like:

  #define assert(condition) do { if (0) { (void)(condition) } } while (0)

But, the code in the asserts hasn’t yet been tested to build. So we
may run into build issues, like the presence of division, or
dependency on libc.

I’ll take a stab at it, but if it ends up requiring too large of a change,
I will tend to continue with the current approach.

Best,
Nick Terrell

>                  Linus