Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail6.b-one.net (Postfix) with ESMTP id CCCEA80150C63
	for <filtered@awaresystems.be>; Sat,  7 Jul 2012 11:06:20 +0200 (CEST)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-s: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.160.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48])
	by mx-s.one.com (Postfix) with ESMTP id 18E321B291F3
	for <filtered@awaresystems.be>; Sat,  7 Jul 2012 09:06:19 +0000 (UTC)
Received: by pbbrq8 with SMTP id rq8so17938496pbb.21
        for <filtered@awaresystems.be>; Sat, 07 Jul 2012 02:06:19 -0700 (PDT)
Received: by 10.66.74.3 with SMTP id p3mr51153830pav.49.1341651979071;
        Sat, 07 Jul 2012 02:06:19 -0700 (PDT)
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.143.92.14 with SMTP id u14csp96882wfl;
        Sat, 7 Jul 2012 02:06:18 -0700 (PDT)
Received: by 10.68.224.233 with SMTP id rf9mr44158633pbc.141.1341651976881;
        Sat, 07 Jul 2012 02:06:16 -0700 (PDT)
Received-SPF: softfail (google.com: best guess record for domain of transitioning tiff-bounces@lists.maptools.org does not designate 91.198.169.250 as permitted sender) client-ip=91.198.169.250;
Received: by 10.68.208.100 with POP3 id md4mf15347716pbc.25;
        Sat, 07 Jul 2012 02:06:16 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail6.b-one.net (Postfix) with ESMTP id 929C780150C63
	for <info@awaresystems.be>; Sat,  7 Jul 2012 10:59:34 +0200 (CEST)
X-Greylist: accepted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-s.one.com (Postfix) with ESMTP id 38EFF1B13A0A
	for <info@awaresystems.be>; Sat,  7 Jul 2012 08:59:34 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id E023B1EDB55;
	Sat,  7 Jul 2012 03:58:15 -0500 (EST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6])
	by lists.maptools.org (Postfix) with ESMTP id 4D4EE1EDB48
	for <tiff@lists.maptools.org>; Sat,  7 Jul 2012 03:37:17 -0500 (EST)
Received: from even-desktop.localnet (unknown [88.162.84.61])
	by smtp6-g21.free.fr (Postfix) with ESMTP id C939D82261;
	Sat,  7 Jul 2012 10:37:11 +0200 (CEST)
From: Even Rouault <even.rouault@mines-paris.org>
To: tiff@lists.maptools.org
Date: Sat, 7 Jul 2012 10:38:17 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-41-generic; KDE/4.4.5; x86_64; ; )
References: <alpine.GSO.2.01.1207061419280.27589@freddy.simplesystems.org>
	<CAAcuQeakZZRzZL-e3-VVueON67+jAOs14Q6VMVDuPhsxV4CitQ@mail.gmail.com>
	<alpine.GSO.2.01.1207061513430.27589@freddy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.01.1207061513430.27589@freddy.simplesystems.org>
MIME-Version: 1.0
Message-Id: <201207071038.17318.even.rouault@mines-paris.org>
Subject: Re: [Tiff] Challenge to properly eliminate warning
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

> I think that the compiler does understand the complex logic and that
> there must be cases where no error is returned but the data was not
> updated.  It requires -O2 optimization level before these issues are
> detected.  At this level, GCC is inlining the short functions in the
> module so it sees a lot of issues it would not otherwise see.
> =

> It only requires a single case where the error indication is not set
> or used correctly so that 'data' gets consumed when it should not be
> in order to produce this warning.
> =

> Unfortunately, there are a multitude of paths executed under
> TIFFReadDirEntryByte() so it is difficult to determine which ones
> might include the weakness.

I agree that gcc -O2 is quite clever, but I'm almost sure that in that case=
 it =

just get lost because of multiple depth of calls, and at some point the =

functions are no more inlined.

Here's my analysis.

If you comment the 'case TIFF_LONG8' and 'case TIFF_SLONG8' blocks in =

TIFFReadDirEntryByte(), no more warning. So for now, let's just comment the =

case TIFF_SLONG8 block :

		case TIFF_LONG8:
			{
				uint64 m;
				err=3DTIFFReadDirEntryCheckedLong8(tif,direntry,&m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				err=3DTIFFReadDirEntryCheckRangeByteLong8(m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				*value=3D(uint8)m;
				return(TIFFReadDirEntryErrOk);
			}
		/*case TIFF_SLONG8:
			{
				int64 m;
				err=3DTIFFReadDirEntryCheckedSlong8(tif,direntry,&m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				err=3DTIFFReadDirEntryCheckRangeByteSlong8(m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				*value=3D(uint8)m;
				return(TIFFReadDirEntryErrOk);
			}
                 */

We still have the warning.

If we try this now :
		case TIFF_LONG8:
			{
				uint64 m;
				/*err=3DTIFFReadDirEntryCheckedLong8(tif,direntry,&m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);*/
				m =3D 0; /* added to avoid warning about m being =

uninitialized */
				err=3DTIFFReadDirEntryCheckRangeByteLong8(m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				*value=3D(uint8)m;
				return(TIFFReadDirEntryErrOk);
			}

No more warning. Interesting, but there's nothing wrong with the commented =

code because if TIFFReadDirEntryCheckedLong8 returns something different th=
an =

TIFFReadDirEntryErrOk, then *value is indeed not initialized, but the calle=
rs =

of that code will not use *value because of the error return code, so that'=
s =

fine.

So my next hypothesis was that there was perhaps something wrong in =

TIFFReadDirEntryCheckedLong8() that didn't always initialize m, causing =

perhaps gcc to warn about *value. Ok, let's test that :

		case TIFF_LONG8:
			{
				uint64 m;
				err=3DTIFFReadDirEntryCheckedLong8(tif,direntry,&m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				m =3D 0; /* still there */
				err=3DTIFFReadDirEntryCheckRangeByteLong8(m);
				if (err!=3DTIFFReadDirEntryErrOk)
					return(err);
				*value=3D(uint8)m;
				return(TIFFReadDirEntryErrOk);
			}

Still the warning about data ! This does not make sense.

So I think that there is too much code in that block, directly or indirectl=
y, =

and that GCC cannot follow all the code paths. We could expect it to not em=
it =

a warning in that case, instead of emitting a false positive.

Proposal : at the beginning of TIFFReadDirEntryByte(), add :

Index: tif_dirread.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- tif_dirread.c	(r=E9vision 24659)
+++ tif_dirread.c	(copie de travail)
@@ -197,6 +197,7 @@
 static enum TIFFReadDirEntryErr TIFFReadDirEntryByte(TIFF* tif, TIFFDirEnt=
ry* =

direntry, uint8* value)
 {
 	enum TIFFReadDirEntryErr err;
+    *value =3D 0;
 	if (direntry->tdir_count!=3D1)
 		return(TIFFReadDirEntryErrCount);
 	switch (direntry->tdir_type)

Another interesting track is that if you don't do the above change, but do =

this instead :

Index: tif_dirread.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- tif_dirread.c	(r=E9vision 24659)
+++ tif_dirread.c	(copie de travail)
@@ -4765,6 +4765,7 @@
 				assert(fip->field_readcount=3D=3D1);
 				assert(fip->field_passcount=3D=3D0);
 				err=3DTIFFReadDirEntryByte(tif,dp,&data);
+                		err=3DTIFFReadDirEntryByte(tif,dp,&data);
 				if (err=3D=3DTIFFReadDirEntryErrOk)
 				{
 					if (!TIFFSetField(tif,dp->tdir_tag,data))

or :

Index: tif_dirread.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- tif_dirread.c	(r=E9vision 24659)
+++ tif_dirread.c	(copie de travail)
@@ -4774,15 +4774,15 @@
 			break;
 		case TIFF_SETGET_UINT16:
 			{
-				uint16 data;
-				assert(fip->field_readcount=3D=3D1);
-				assert(fip->field_passcount=3D=3D0);
-				err=3DTIFFReadDirEntryShort(tif,dp,&data);
-				if (err=3D=3DTIFFReadDirEntryErrOk)
-				{
-					if (!TIFFSetField(tif,dp->tdir_tag,data))
-						return(0);
-				}
+                		uint8 data;
+                		assert(fip->field_readcount=3D=3D1);
+                		assert(fip->field_passcount=3D=3D0);
+                		err=3DTIFFReadDirEntryByte(tif,dp,&data);
+                		if (err=3D=3DTIFFReadDirEntryErrOk)
+                		{
+                   			 if (!TIFFSetField(tif,dp->tdir_tag,data))
+                       			 return(0);
+                		}
 			}
 			break;
 		case TIFF_SETGET_UINT32:


The warning also disappears ! So this is a hint that at some point, GCC get=
s =

lost because it doesn't want to inline any more.

Other track: the warning only appears with GCC 4.7.0. I tried GCC 3.4, 4.1, =

4.3, 4.4, 4.5 and 4.6, clang 3.0 and 3.1, and none emits the warning. Perha=
ps =

is it a bug of GCC 4.7.0 ?

> =

> Bob
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
