mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: puwenxu <>
Cc: "" <>
Subject: Re: [musl] Question on 2b2c8aafce9d80f9d58652643538f4d58e82b856
Date: Sun, 30 Oct 2022 10:31:02 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Oct 30, 2022 at 06:29:54AM +0000, puwenxu wrote:
> Dear maintainer,
>        I'm using musl 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.


  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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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

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).