Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: mergesort code segfaulting on smallish arrays
Date: Sun, 10 Nov 2019 05:27:18 -0800
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <86d0dzdfpl.fsf@linuxsc.com>
References: <zVWwF.94046$oT5.45971@fx47.iad> <qq3qs7$4qf$1@news.albasani.net> <87mud63p3b.fsf@bsb.me.uk> <86o8xlem9f.fsf@linuxsc.com> <8736ew4zav.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="451385503b6e65ada0ba6f97513c8763"; logging-data="5612"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18eECWCMKttMuMdpxHPvcp+fFeiEzm68Xo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:RY9b55eZbHuvnutzl6R+jgDno/U= sha1:t6Hb4s33MeAxpC4QGXlS0XkRNV8=
Xref: csiph.com comp.lang.c:147878

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> int randIt( int low, int high )
>>>> {
>>>>     return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>>>> }
>>>
>>> This function has numerous problems.  [...]  perhaps the most
>>> dangerous is that it can return high.  [...]
>>
>> Isn't it the case that the routine being discussed is supposed to
>> be able to return the value high?  More specifically, that the
>> interval of possible values is meant to include both endpoints?
>> I thought it was.
>
> There have been programs posted with both forms -- where the range is
> taken to be either [low, high] or [low, high).

My impression was they all were meant to be of the [low, high] form.
But then I wasn't paying very close attention so I easily could have
missed something.  Anyway, no matter.

> The problem here is quite different.  The return of the high value is
> just a bug in this function since it occurs only when rand() returns
> RAND_MAX so either the frequency with which high is returned is wrong,
> or the fact that happens at all is wrong.

Right.  I already understood this from your earlier comment and just
didn't say anything about it.  We might say the frequency is wrong
in both cases - far too low if high is meant to be included, and far
too high (infinitely so) if it isn't.