Open GoogleCodeExporter opened 9 years ago
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 Stephen....@gmail.com
on 24 Feb 2010 at 12:08
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 gaoz...@gmail.com
on 25 Feb 2010 at 5:38
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 Stephen....@gmail.com
on 25 Feb 2010 at 6:24
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 Stephen....@gmail.com
on 25 Feb 2010 at 6:30
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 gaoz...@gmail.com
on 25 Feb 2010 at 6:39
Argh; when cross-compiling for 32-bit, I only get warnings in the included
example tests, not in cmockery
itself.
Original comment by Stephen....@gmail.com
on 25 Feb 2010 at 7:07
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 Stephen....@gmail.com
on 25 Feb 2010 at 7:47
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 gaoz...@gmail.com
on 26 Feb 2010 at 1:57
Original issue reported on code.google.com by
gaoz...@gmail.com
on 25 Nov 2009 at 6:44Attachments: