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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.