mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] Question on 2b2c8aafce9d80f9d58652643538f4d58e82b856
Date: Sun, 30 Oct 2022 18:11:07 +0100	[thread overview]
Message-ID: <20221030171107.GA1992@voyager> (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.  [cid:image001.png@01D8EC6C.12AE8540] 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.
> [cid:image002.png@01D8EC6C.12AE8540]
> [cid:image003.png@01D8EC6C.12AE8540] Looking forward to your reply.
>
>
>
> Wish Pu OS Kernel Lab
>

Hi,

as the others already said, please avoid images if text would also do.

I do also note that it appears you Huawei people have a bee in your
bonnet about NULL pointer checks. musl does not plaster over bad
behavior. In the cases where a NULL pointer argument would be
dereferenced, it was undefined behavior to give a NULL pointer argument
in the first place. I do agree that programs need to be prevented from
dereferencing NULL pointers, but the place to do so is after creating
the pointers and before handing it to an API that does not accept NULL
pointers. And yes, it does suck that C is incapable of expressing the
idea of a non-nullable pointer natively, but C is the language we're
stuck with.

Your test program only shows that by default, dereferencing the NULL
pointer on Linux crashes. This is well-known, though not behavior you
can rely upon since it can be overridden if you know how. In any case,
having a pointer which ought to point at an object point to nothing is a
logic error that needs to be rectified in the calling code. Just check
your malloc() returns, it isn't that difficult!

Ciao,
Markus

  parent reply	other threads:[~2022-10-30 17:11 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
2022-10-30 17:11 ` Markus Wichmann [this message]
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=20221030171107.GA1992@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.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).