Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: double free
Date: Mon, 11 Jul 2016 11:02:10 -0700
Organization: None to speak of
Lines: 22
Message-ID: <lny458jbod.fsf@kst-u.example.com>
References: <d5964270-015f-4955-9f7a-6a06bcfb5944@googlegroups.com> <577ba42f.13700328@news.xs4all.nl> <slrnnnqlqn.5q5.grahn+nntp@frailea.sa.invalid> <48c43c3f-8e7e-0509-5b9d-04133e7bb537@verizon.net> <pan.2016.07.09.05.13.42.40000@nowhere.invalid> <d3c0b115-927f-af9a-2c65-7893df4cbba9@verizon.net> <nlrfm4$fgs$1@dont-email.me> <e05fc20f-5e8f-8e6c-1f19-4e156bf337de@verizon.net> <nlt4ns$245$1@dont-email.me> <nlu9j4$1v8$1@dont-email.me> <nlvk42$m4u$1@dont-email.me> <nm02k9$7bq$1@dont-email.me> <d31ce5fb-3d80-4edf-b0cb-4a3bae6a4c65@googlegroups.com> <1b37ngjfpc.fsf@pfeifferfamily.net> <e36d885b-9144-4bef-a268-fad330b46d84@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="15834"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19BcEw9YbcZjA1ad8y7i+Fj"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:b8DvFqXAoD68/XvnSTZmPO68nS8= sha1:OHKS6f+dXqEQYflsnM+kFZnVSnA=
Xref: csiph.com comp.lang.c:90220

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> When we change the precision, we also change the behaviour of code
> when we approach the limits. In this case, hypothetically, the result
> is a number scaled to be about unity, and the array contains terms of
> descending magnitude which are summed to achieve the result. So if our
> results are single precision floats, we can stop when the value goes
> below FLT_EPSILON or thereabout, and we might know that will happen
> within ten steps.
> If we move to double, we've got to decide whether we need more
> accuracy. Probably the reason for the change is that we do. So we'll
> need more steps.
>
> But the change is a consequence of changing the type.

And casting the result of malloc() is your solution?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"