Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: double free Date: Mon, 11 Jul 2016 10:57:55 -0700 Organization: None to speak of Lines: 38 Message-ID: References: <577ba42f.13700328@news.xs4all.nl> <48c43c3f-8e7e-0509-5b9d-04133e7bb537@verizon.net> 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="U2FsdGVkX19L1ghVZaFLnbLjWQe7eFjj" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/52AqG3Uk/2EGIzbt3+w2gJl/Rk= sha1:rD2Rh8XklBXwLzYaf2srul18lZc= Xref: csiph.com comp.lang.c:90218 Malcolm McLean writes: > On Monday, July 11, 2016 at 1:15:14 PM UTC+1, James Kuyper wrote: >> And it's precisely that point I'm disputing: the fact that the data type >> has changed provides no reason why that particular line needs any of >> your attention. It was deliberately written in such a way as to make the >> type irrelevant. Time spent checking it is wasted - you should spend >> that time checking the lines where the type actually matters. >> > We need ten floats for some reason. > We then decide to shift the calculation into double precision. > So how many doubles do we need? Usually, we'll still need ten. But not > always. Say they are coefficients in a series, the tenth of which is > about FLT_EPSILON. Clearly, we're going to have to add a few more > terms to get the value down to DBL_EPSILON. > > That's what David and I mean about needing to check all the code by hand. Say you change a type from integer to floating-point, or vice versa. Among other things, you'll probably need to check all division operators on that type, since the semantics are different. There are probably no casts to help you find them. If you change a type, you'll probably have to change all the affected code anyway. Using casts on malloc() calls to remind you to check those particular calls is a trick with a very low payoff, and a non-zero cost both in added complexity and in making casts (which *should* be a warning that something odd is going on) seem normal and harmless. And if you're dealing with any code written by other people, you'll probably have to deal with castless malloc() calls anyway, so I suggest you get used to it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"