[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetype-devel
Subject:    Re: [ft-devel] freetype, undefined behaviour, and clang
From:       Antoine Leca <Antoine-Freetype () Leca-Marti ! org>
Date:       2011-11-28 18:09:27
Message-ID: 4ED3CE57.6080106 () Leca-Marti ! org
[Download RAW message or body]

Sean McBride wrote:

Clang is an interesting tool to discover that sort of gotchas.


> 360	      if ( (FT_ULong)(type->flags - FT_INT_MIN) > FT_UINT_MAX )
This one should really look like

		if ( (FT_ULong)type->flags - FT_INT_MIN > FT_UINT_MAX )

according to ANSI C : since FT_INT_MIN has a lesser rank than FT_Ulong
(both because FT_Int has less rank than FT_Long and because signed
promotes to unsigned in ANSI C), in the latter form the - operation is
always done on unsigned values, so cannot overflow; the result is the
same as the former except for the overflow possibility.

Now, the purpose of such a test I am not sure I understand; if the
purpose is to detect any flag set outside the range of FT_Int, then
		if ( type->flags > FT_INT_MAX )
should do the same work in a somewhat cleaner way, shouldn't it? And
then, the error message next line is a slight misfit:
	"0x%x are dropped\n", (type->flags & ~((FT_ULong)FT_UINT_MAX))
(and there is another catch there, the format specifier should be %lx.)
And if the real intent is what the error message states, then
		if ( type->flags > FT_UINT_MAX )
would do the job.


Again, clang is indeed an interesting tool... and it takes time to
analyse each and every warning.


Antoine


_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[prev in list] [next in list] [prev in thread] [next in thread]