linux-kernel - Re: [PATCH] [RFC v2] qnx: avoid -Wstringop-overread warning, again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Sep 2021 08:40:24 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Anders Larsen <al@...rsen.net>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC v2] qnx: avoid -Wstringop-overread warning, again

On Tue, Sep 21, 2021 at 8:15 AM Anders Larsen <al@...rsen.net> wrote:
>
> they are available at the same offsets in struct qnx4_link_info as well, so
> wouldn't it be even simpler to just always use the fields of the latter
> structure?

I'd rather use that third "clearly neither" structure member, just to
clarify what is going on.

Yes, we could just always use the bigger structure, but then we'd
actually access a "link entry" even when it really isn't a link entry.

Now we can have that bogus entry and the big comment that says exactly
why we use the bogus entry, and it's clear that the "name" we use is
not necessarily a link entry or an inode entry, it's that special
union with a big comment about a gcc bug above it..

Anyway, I committed my patch that Arnd had tested, with a slightly
expanded comment. I'm sure yours would have compiled cleanly too.

           Linus