a warning-clean patch based on svn r.42

[google]

a warning-clean patch based on svn r.42

[GoogleCodeExporter]

I merged this patch into cmockery-staging. However, on all of my platforms I 
get warnings when compiling 
cmockery (with or without these patches) so I cannot test the merge. Please 
test revision 466b93dee4 from 
<http://code.google.com/p/cmockery-staging/source/checkout> in your compilation 
environments and let me 
know if they compile without warnings for you. Thanks.

Original comment by [email protected] on 24 Feb 2010 at 12:08

[GoogleCodeExporter]

What warnings did you get, and what platforms have you tested?

What is the goal of the cmockery-staging experiment, fixing bugs for the 
official 
one, or adding new features, or even a new unit test framework in the future?

I checked out cmockery-staging rev.466b93dee4, and compile with gcc 3.4.5 and 
gcc 
4.4 on WinXP SP3 and mingw.

For Gcc 3.4.5, 
  gcc -std=c99 -Wall -Wextra -Werror -pedantic            -I google -c cmockery.c
  gcc -std=c99 -Wall -Wextra -Werror -pedantic         -g -I google -c cmockery.c
  gcc -std=c99 -Wall -Wextra -Werror -pedantic -O6 -Os    -I google -c cmockery.c
  gcc -std=c99 -Wall -Wextra -Werror -pedantic -O6 -Os -g -I google -c cmockery.c
all without warnings.

For Gcc4.4, 
  gcc -std=c99 -Wall -Wextra -Werror -pedantic            -I google -c cmockery.c
  gcc -std=c99 -Wall -Wextra -Werror -pedantic         -g -I google -c cmockery.c
both without warnings, but:
  gcc -std=c99 -Wall -Wextra -Werror -pedantic -O6 -Os    -I google -c cmockery.c
  gcc -std=c99 -Wall -Wextra -Werror -pedantic -O6 -Os -g -I google -c cmockery.c
give one warning: Variable 'state' might get clobbered by 'longjmp'. Declaring 
state 
as "void ** const volatile state" on line cmockery.c:1587, can avoid this 
warning.

Original comment by [email protected] on 25 Feb 2010 at 5:38

[GoogleCodeExporter]

Thank you for testing this, and for the fix for the warning.

My platforms are Mac OS X 10.6.2 with Xcode 3.2.1 on a 64-bit x86 platform:

gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

I get many warnings of the following form:

src/cmockery.c: In function 'initialize_source_location':
src/cmockery.c:283: warning: cast from pointer to integer of different size

I also get these warnings on a CentOS system with a 64-bit x86 processor:

$ cat /etc/*-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
$ uname -p
x86_64
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)

When I cross-compile on Mac OS X with Xcode for a 32-bit platform, I do not get 
any warnings.

As far as the goal of cmockery-staging, I would defer to Alexander Demin, but I 
think it is an experimental 
fork for adding some features which apparently haven't gained favor with the 
cmockery maintainers. However, 
since the cmockery maintainers have been missing lately, I have been 
integrating fixes which have not been 
included in the cmockery repository. I also intended to put my 64 bit 
portability fixes into cmockery-staging. 
However, with the reappearance of Stewart Miles, maybe cmockery-staging will be 
less needed.

Are you a member of the cmockery Google group?

Original comment by [email protected] on 25 Feb 2010 at 6:24

[GoogleCodeExporter]

Sorry, I was wrong in saying I do not get warnings when cross-compiling for 
32-bit x86; I get warnings in this 
case also.

Original comment by [email protected] on 25 Feb 2010 at 6:30

[GoogleCodeExporter]

No, I'm not. I also want to see the reappearance of Stewart Miles, hoho^^

For the warning, it is caused by:
  #define cast_to_largest_integral_type(value) \
    ((LargestIntegralType)((unsigned)(value)))
where `value' is a 64-bit pointer.
Try like this:
  #define cast_to_largest_integral_type(value) \
    ((LargestIntegralType)((uintptr_t)(value)))

Original comment by [email protected] on 25 Feb 2010 at 6:39

[GoogleCodeExporter]

Argh; when cross-compiling for 32-bit, I only get warnings in the included 
example tests, not in cmockery 
itself.

Original comment by [email protected] on 25 Feb 2010 at 7:07

[GoogleCodeExporter]

I haven't convinced myself that casting to uintptr_t is correct; there may be 
cases where the value argument is 
larger than a uintptr_t. Consider an LP64 platform that defines long long as 
128 bits.

I've fixed this in my own fork by simply removing the (incorrect) cast to 
unsigned. This cures the warnings on 
LP64 platforms, but introduces a series of warnings on ILP32 platforms.

I'm considering a more involved reworking that attempts to avoid casting 
between pointers and integral types 
whenever possible.

Original comment by [email protected] on 25 Feb 2010 at 7:47

[GoogleCodeExporter]

Yes, I know this problem. For pointer, it must be converted to (u)intptr_t 
first, 
whereas the integer must be converted directly to intmax_t. And for 
float/double/long double, it shouldn't be converted to integer in assert_true.

So, we may be need some special macro/function for different types. Or, we need 
a 
mechanism like c++ template.

Original comment by [email protected] on 26 Feb 2010 at 1:57