From: Kevin Bracey <kevin@bracey.fi>
To: "GIT Mailing-list" <git@vger.kernel.org>, "René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH 1/3] add QSORT
Date: Mon, 03 Oct 2016 20:09:48 +0300 [thread overview]
Message-ID: <57F290DC.5080303@bracey.fi> (raw)
In-Reply-To: <83398160-555f-adab-6b1e-3283c533b5ff@web.de>
On 01/10/2016 19:19, René Scharfe wrote:
>
> It's hard to imagine an implementation of qsort(3) that can't handle
> zero elements. QSORT's safety feature is that it prevents the compiler
> from removing NULL checks for the array pointer. E.g. the last two
> lines in the following example could be optimized away:
>
> qsort(ptr, n, sizeof(*ptr), fn);
> if (!ptr)
> do_stuff();
>
> You can see that on https://godbolt.org/g/JwS99b -- an awesome website
> for exploring compilation results for small snippets, by the way.
>
Ah, second attempt. Originally misread the original code, and didn't
understand what it was doing.
I get it now.
A nasty trap I hadn't been aware of - I was under the impression NULL +
zero length was generally legal, but the C standard does indeed not give
you a specific out for NULL to library functions in that case.
As such, NULL checks can still be elided even with your change. If you
effectively change your example to:
if (nmemb > 1)
qsort(array, nmemb, size, cmp);
if (!array)
printf("array is NULL\n");
array may only be checked for NULL if nmemb <= 1. You can see GCC doing
that in the compiler explorer - it effectively turns that into "else
if". To make that check really work, you have to do:
if (array)
qsort(array, nmemb, size, cmp);
else
printf("array is NULL\n");
So maybe your "sane_qsort" should be checking array, not nmemb.
Kevin
next prev parent reply other threads:[~2016-10-03 17:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 15:23 [PATCH 1/3] add QSORT René Scharfe
2016-09-29 15:27 ` [PATCH 2/3] use QSORT René Scharfe
2016-09-29 15:29 ` [PATCH 3/3] remove unnecessary check before QSORT René Scharfe
2016-09-29 22:36 ` [PATCH 1/3] add QSORT Junio C Hamano
2016-09-29 23:21 ` René Scharfe
2016-09-29 23:40 ` René Scharfe
2016-10-01 16:19 ` René Scharfe
2016-10-03 16:46 ` Kevin Bracey
2016-10-03 17:09 ` Kevin Bracey [this message]
2016-10-03 22:00 ` René Scharfe
2016-10-04 5:28 ` Kevin Bracey
2016-10-04 20:31 ` René Scharfe
2016-10-05 15:00 ` Kevin Bracey
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=57F290DC.5080303@bracey.fi \
--to=kevin@bracey.fi \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
/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.