Comments (8)
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
from cmockery.
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
from cmockery.
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
from cmockery.
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
from cmockery.
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
from cmockery.
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
from cmockery.
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
from cmockery.
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
from cmockery.
Related Issues (20)
- Integer conversion warning on HP-UX HOT 2
- strsignal() function is on available on HP-UX IA64 v3 HOT 3
- char* to int conversion truncation warning on HP-UX in 64-bit mode
- stdout and stderr outputs could be messed up
- Add headers for regular case
- Problem when mocking printf
- COPYING appears to contradict actual license
- Problem in running test HOT 1
- gcc compiler warning: format not a string literal and no format arguments
- many portability issues in printf format specifiers
- free_symbol_map_value casts pointer to smaller integral type on LP64 platforms
- mock_assert attempts to pass pointer through longjmp int argument on LP64 platforms
- _test_free() casts pointer to int on LP64 platforms
- mock_assert attempts to pass pointer via int argument to longjmp HOT 1
- Some warnings related with printf and derivates.
- Freeing memory allocated by realloc() throw's error HOT 1
- _test_free causes testcase to fail when called with ptr = 0
- index.html fail_connect_to_customer_database() code doesn't match example source
- check_expected causes segfault.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmockery.