Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-x.one.com (mx-x.one.com [195.47.247.149])
	by mail6.local.one.com (Postfix) with ESMTP id A30FC30021E0F8
	for <filtered@awaresystems.be>; Tue,  6 Jan 2015 04:35:18 +0000 (UTC)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-x: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.215.51 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51])
	by mx-x.one.com (Postfix) with ESMTP id 6755121BBB3CD
	for <filtered@awaresystems.be>; Tue,  6 Jan 2015 04:35:18 +0000 (UTC)
Received: by mail-la0-f51.google.com with SMTP id ms9so19281007lab.10
        for <filtered@awaresystems.be>; Mon, 05 Jan 2015 20:35:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:delivered-to:delivered-to
         :message-id:date:from:user-agent:mime-version:to:references
         :in-reply-to:cc:subject:precedence:list-id:list-unsubscribe
         :list-archive:list-post:list-help:list-subscribe:content-type
         :content-transfer-encoding:sender:errors-to;
        bh=Q7j7dT1zVnwwKu+UHsQFZIgdHF0AE8K73h8PeXONLtY=;
        b=J7Xs8tbuJ4gzMoFtosVTKGyo7M+5vamiXXFw+ZydaOY1ZWanCneuQigBj/CRZgbSP5
         VT/zNUe8UfIrXG08Z4LPhuqyQ69W0LfZHXjA5cyxNEoF7nSCeBLMhSxeJ0LHu9EGYFHd
         f2TjX4Nf/gujUqii8jotDBA8m1GaUiPQF5A8DuWAAKHBDLRG1BghbeI3KHvTWFGfd4Do
         qNIwNxR/Umvv4PqEPPaY0QlcMtnhVTqfsa+TCD4lC2Nevq2GNvqg156fvRKjZJr+SQpA
         /6PdksFyV56kYahnQusbJ/3T306LIoSZHkdvUBv7zZQnG/BU9kYJsoUduUMn3Oy/cznR
         iLhg==
X-Original-Authentication-Results: mx.google.com;       spf=none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) smtp.mail=tiff-bounces@lists.maptools.org
X-Received: by 10.152.5.198 with SMTP id u6mr98348298lau.42.1420518918148;
        Mon, 05 Jan 2015 20:35:18 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.114.181.147 with SMTP id dw19csp3807746ldc;
        Mon, 5 Jan 2015 20:35:17 -0800 (PST)
X-Received: by 10.113.11.12 with SMTP id ee12mr70704369lbd.79.1420518916738;
        Mon, 05 Jan 2015 20:35:16 -0800 (PST)
Authentication-Results: mx.google.com;
       spf=none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) smtp.mail=tiff-bounces@lists.maptools.org
Received-SPF: none (google.com: tiff-bounces@lists.maptools.org does not designate permitted sender hosts) client-ip=91.198.169.58;
Received: by 10.112.74.9 with POP3 id p9mf19639946lbv.24;
        Mon, 05 Jan 2015 20:35:16 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail6.local.one.com (Postfix) with ESMTP id F321730021E0FE
	for <info@awaresystems.be>; Tue,  6 Jan 2015 04:22:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (ks365428.kimsufi.com [94.23.4.142])
	by mx-k.one.com (Postfix) with ESMTP id BE666D980D3
	for <info@awaresystems.be>; Tue,  6 Jan 2015 04:22:38 +0000 (UTC)
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 60BA435C078;
	Mon,  5 Jan 2015 23:21:46 -0500 (EST)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com
	[209.85.217.174])
	by lists.maptools.org (Postfix) with ESMTPS id B365A35C055
	for <tiff@lists.maptools.org>; Mon,  5 Jan 2015 23:17:02 -0500 (EST)
Received: by mail-lb0-f174.google.com with SMTP id 10so18555404lbg.5
	for <tiff@lists.maptools.org>; Mon, 05 Jan 2015 20:17:10 -0800 (PST)
X-Received: by 10.112.85.11 with SMTP id d11mr96811420lbz.100.1420517829998;
	Mon, 05 Jan 2015 20:17:09 -0800 (PST)
Received: from ?IPv6:2a00:1370:8000:eff::3c6b? ([2a00:1370:8000:eff::3c6b])
	by mx.google.com with ESMTPSA id
	ji6sm15113734lbb.26.2015.01.05.20.17.09
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 05 Jan 2015 20:17:09 -0800 (PST)
Message-ID: <54AB61C4.5040901@gmail.com>
Date: Tue, 06 Jan 2015 07:17:08 +0300
From: "Yuriy M. Kaminskiy" <yumkam@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Olivier Paquet <olivier.paquet@gmail.com>
References: <54A30DF9.4090109@gmail.com>	<1419972943.29851.19.camel@t-online.de>	<CAAcuQeYoapa-7CJ==3km+i3EWrCxU66i3jSSViSd--tc4_VMVw@mail.gmail.com>	<alpine.GSO.2.01.1412310958020.18732@freddy.simplesystems.org>
	<CAAcuQeb--79s8guKm185+g0JRmjgvecWRWf_NbwBSbp6JXZnWw@mail.gmail.com>
In-Reply-To: <CAAcuQeb--79s8guKm185+g0JRmjgvecWRWf_NbwBSbp6JXZnWw@mail.gmail.com>
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] [PATCH] tif_luv, tif_pixarlog,
 ppm2tiff: get rid of duplicates of TIFFSafeMultiply
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Olivier Paquet wrote:
> 2014-12-31 11:04 GMT-05:00 Bob Friesenhahn <bfriesen@simple.dallas.tx.us>:
>> Whatever is done, it would be good if the approach is normalized rather than
>> creating many one-of solutions in the code.
> 
> I agree, as soon as we can figure out what to normalize it too :-)
> 
> For now, I have fixed checkAdd64 since it was plain nonsense. I have
> left the _ms functions alone since, as Yuriy pointed out, the multiply
> is also unreliable because of undefined behavior (of signed int
> overflow). This means TIFFSafeMultiply with tmsize_t is not a proper
> solution either as currently written.
> 
> I think the easist fix for those would be to do the math with unsigned
> integers after validation that the input is nonnegative. Full check of

If input is non-negative, IMO, better check for multiplication overflow is
  (a) > type##_MAX/((b) | ((b) == 0)) ? 0 : (a)*(b)

Same with addition overflow (again, assuming non-negative a and b):
  (a) > type##_MAX - (b) ? 0 : (a)+(b)

(assuming tmsize_t_MAX, uint32_MAX, etc was added to tiffconf.h.in)

BTW, while checking for other "duplicates of TIFFSafeMultiply" I also noticed *a
lot* of places with code like:

  uint64 foo;
  tmsize_t bar;
  ...
  bar = (tmsize_t)foo;
  if ((uint64)bar != foo) {
     /* throw integer overflow */
  }

Obviously, this check will fail to catch "foo > INT64_MAX" on 64-bit platform;
and I'm not totally sure about overly "smart" compilers on 32-bit platforms either.
IMO, this should be replaced with

   if (foo > tmsize_t_MAX) {
     /* throw integer overflow */
   }
   bar = foo;

> signed integer multiply is also possible but it is more code than I'm
> comfortable putting in a macro.
> 
>> There is value gained from using pre-processor macros in that they do not
>> influence the values type.  Hard-coded functions may produce an unexpected
>> result if the function prototype converts the input value to a different
>> type.  For example, if size_t is assumed, then there could be a problem if
>> the computation is intentionally using types larger than size_t, or a signed
>> type.
>
> Macros can be misused in many ways as well. As pointed out above, you
> don't know the data type in the macro and the code needed to detect
> overflow should be different for signed/unsigned data. It gets even
> worse if you accidentally mix signed and unsigned. I'm not sure C
> offers any good solution to prevent programmer error here. It all
> comes down to using the macro/function properly.
> 
> With that said, as libtiff has fairly few use cases, I think we could
> write different macros to handle them (ie. tmsize_t multiply, uint32
> multiply, uint64 multiply, ...). Hopefully someone will have a better
> idea.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
