Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jun 2010 11:19:10 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, src-committers@freebsd.org
Subject:   Re: svn commit: r209358 - head/cddl/contrib/opensolaris/lib/libdtrace/common
Message-ID:  <B0645608-F3E0-49FA-88A6-283F36FCF759@mac.com>
In-Reply-To: <20100622024652.C43995@delplex.bde.org>
References:  <201006200034.o5K0Y6xl041024@svn.freebsd.org> <20100622024652.C43995@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jun 21, 2010, at 10:22 AM, Bruce Evans wrote:

> On Sun, 20 Jun 2010, Marcel Moolenaar wrote:
> 
>> Log:
>> Unbreak platforms with char unsigned by default. Oddly enough, GCC isn't
>> satisfied with a simple cast to int in the check against EOF, so the fix
>> is a bit involved by actually having to go through a temporary variable.
> 
> Perhaps that is because gcc can see that the cast has no effect, so the
> comparison can never be true if `c' is an unsigned char (unless unsigned
> char has the same number of bits as signed int), but it cannot see that
> the conversion to the temporary variable has the same null effect.

Very likely. However, by casting from char to int we do tell the
compiler that this not grounds for a warning and as such we expect
the compiler to treat this as any other scenario in which the
compiler can infer that a condition is always true or false and
as such optimize correctly.

In other words: the compiler is correct in warning that (u_char != -1)
is possibly not what the programmer wants, but I do expect that if we
change the condition to (int != -1) by using a cast that the compiler
will simply shut up and eliminate the if statement if it knows that
the int will never be -1.

> This remains broken, especially on platforms with chars unsigned.

I can't make that claim. The expansion of the macro in the failing
case may actually not have a problem by virtue of it working on an
array of unsigned char. For all I know, EOF is never encountered
and the check is simply not applicable.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B0645608-F3E0-49FA-88A6-283F36FCF759>