From: Rich Felker <dalias@libc.org>
To: puwenxu <puwenxu1@huawei.com>
Cc: "musl@lists.openwall.com" <musl@lists.openwall.com>
Subject: Re: [musl] Question on 2b2c8aafce9d80f9d58652643538f4d58e82b856
Date: Sun, 30 Oct 2022 10:31:02 -0400 [thread overview]
Message-ID: <20221030143101.GB29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <1903ff21f49146998d843cc2860f7166@huawei.com>
On Sun, Oct 30, 2022 at 06:29:54AM +0000, puwenxu wrote:
> Dear maintainer,
> I'm using musl 1.2.3.0 now. When I was running some test case
> codes for musl, I found there may be a problem on modification of
> 2b2c8aafce9d80f9d58652643538f4d58e82b856.
> As you can see in the picture, this modification assign buf
> to orig. Then, the orig will be assigned to buf again. If the
> original value of buf is NULL, the latter value of the buf will be
> NULL. However, assign out to buf will fail if buf is NULL.
Rather than pointing at what you think is wrong in the source change,
can you demonstrate a minimal example of calling code that was correct
and worked before the change, but fails after the change?
As best I can tell, your concern is about the case where you pass a
null pointer as buf when using one of the msgctl commands that
requires a pointer to a buffer. This is undefined.
> I have written a simple file to verification my opinion. The
> test code and output is shown in the following picture. I think it
> may be better to add a check for buf in this situation.
This isn't an example. An example would be a minimal program that
calls msgctl in a valid (i.e. no undefined behavior) way and
malfunctions as a result of the change.
Rich
next prev parent reply other threads:[~2022-10-30 14:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-30 6:29 puwenxu
2022-10-30 13:11 ` Sam James
2022-10-30 14:31 ` Rich Felker [this message]
2022-10-30 17:11 ` Markus Wichmann
2022-10-31 15:41 puwenxu
2022-10-31 17:25 ` Rich Felker
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=20221030143101.GB29905@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=puwenxu1@huawei.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).