From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: "Greg Kurz" <groug@kaod.org>, "Eric Blake" <eblake@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH] 9pfs: fix dead code in qemu_open_flags_tostr()
Date: Tue, 11 Feb 2025 11:21:34 +0100 [thread overview]
Message-ID: <18703295.KUYhaFHJxC@silver> (raw)
In-Reply-To: <2cfca5f9-4c2f-4777-bfb9-4700005780ec@linaro.org>
On Monday, February 10, 2025 4:32:08 PM CET Philippe Mathieu-Daudé wrote:
> On 10/2/25 15:33, Christian Schoenebeck wrote:
> > Coverity scan complained about expression "|LARGEFILE" to be non reachable
> > and the detailed Coverity report claims O_LARGEFILE was zero. I can't
> > reproduce this here, but I assume that means there are at least some
> > system(s) which define O_LARGEFILE as zero.
>
> Is O_LARGEFILE a Linux-ism?
Ah right, O_LARGEFILE is indeed Linux-specific, not POSIX.
> Commit 67b915a5dd5 ("win32 port (initial patch by kazu)") started to
> define it to 0 on 32-bit Windows. It isn't defined on my 64-bit Darwin,
> and apparently nor on other BSDs.
Yeah, that explains why O_LARGEFILE was defined as zero. I'll adjust the
commit log message at least on my end. The code change itself is appropriate.
Thanks!
/Christian
> > This is not really an issue, but to silence this Coverity warning, add a
> > preprocessor wrapper that checks for O_LARGEFILE being non-zero for this
> > overall expression. The 'defined(O_LARGEFILE)' check is not necessary,
> > but it makes it more clear that we really want to check for the value of
> > O_LARGEFILE, not just whether the macro was defined.
> >
> > Fixes: 9a0dd4b3
> > Resolves: Coverity CID 1591178
> > Reported-by: Coverity Scan
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > ---
> > hw/9pfs/9p-util-generic.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/hw/9pfs/9p-util-generic.c b/hw/9pfs/9p-util-generic.c
> > index 4c1e9c887d..02e359f17b 100644
> > --- a/hw/9pfs/9p-util-generic.c
> > +++ b/hw/9pfs/9p-util-generic.c
> > @@ -19,7 +19,9 @@ char *qemu_open_flags_tostr(int flags)
> > #ifdef O_DIRECT
> > (flags & O_DIRECT) ? "|DIRECT" : "",
> > #endif
> > + #if defined(O_LARGEFILE) && O_LARGEFILE != 0
> > (flags & O_LARGEFILE) ? "|LARGEFILE" : "",
> > + #endif
> > (flags & O_DIRECTORY) ? "|DIRECTORY" : "",
> > (flags & O_NOFOLLOW) ? "|NOFOLLOW" : "",
> > #ifdef O_NOATIME
>
>
>
next prev parent reply other threads:[~2025-02-11 10:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 14:33 [PATCH] 9pfs: fix dead code in qemu_open_flags_tostr() Christian Schoenebeck
2025-02-10 15:32 ` Philippe Mathieu-Daudé
2025-02-11 10:21 ` Christian Schoenebeck [this message]
2025-02-11 14:47 ` Peter Maydell
2025-02-11 15:44 ` Christian Schoenebeck
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=18703295.KUYhaFHJxC@silver \
--to=qemu_oss@crudebyte.com \
--cc=eblake@redhat.com \
--cc=groug@kaod.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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;
as well as URLs for NNTP newsgroup(s).