google/cmockery

A lightweight library to simplify and generalize the process of writing unit tests for C applications.

Cmockery Unit Testing Framework

Contents

• Overview
• Building
• Motivation
• Community

Cmockery is a lightweight library that is used to author C unit tests.

Overview

Cmockery tests are compiled into stand-alone executables and linked with the Cmockery library, the standard C library, and the module being tested. Any symbols external to the module being tested should be mocked - replaced with functions that return values determined by the test - within the test application. Even though significant differences may exist between the target execution environment of a code module and the environment used to test the code, the unit testing is still valid since its goal is to test the logic of a code modules at a functional level and not necessarily all of its interactions with the target execution environment.

It may not be possible to compile a module into a test application without some modification; therefore, the preprocessor symbol UNIT_TESTING should be defined when Cmockery unit test applications are compiled so code within the module can be conditionally compiled for tests.

More detailed information about the mechanics of writing tests with Cmockery can be found in docs/user_guide.md.

Building

To compile the Cmockery library and example applications on Linux, run:

$ ./configure
$ make

To compile on Windows, run:

> vsvars.bat
> cd windows
> nmake

This code has been tested on Linux (Ubuntu) and Windows using VC++7 and VC++8.

Motivation

There are a variety of C unit testing frameworks available; however, many of them are fairly complex and require the latest compiler technology. Some development requires the use of old compilers which makes it difficult to use some unit testing frameworks. In addition, many unit testing frameworks assume the code being tested is an application or module that is targeted to the same platform that will ultimately execute the test. Because of this assumption, many frameworks require the inclusion of standard C library headers in the code module being tested, which may collide with the custom or incomplete implementation of the C library utilized by the code under test.

Cmockery only requires a test application is linked with the standard C library which minimizes conflicts with standard C library headers. Also, Cmockery tries avoid the use of some of the newer features of C compilers.

This results in Cmockery being a relatively small library that can be used to test a variety of exotic code. If a developer wishes to simply test an application with the latest compiler, then other unit testing frameworks may be preferable.

Community

If you have questions about Cmockery, use the following resources:

• Stack Overflow: use the cmockery tag

• Mailing list: cmockery (at) googlegroups.com (archives)

  To join with a Google account, use the web UI; to subscribe/unsubscribe with an arbitrary email address, send an email to:

  • cmockery+subscribe (at) googlegroups.com
  • cmockery+unsubscribe (at) googlegroups.com

License

Cmockery is licensed under the Apache 2.0 license; please see LICENSE.txt for details.

cmockery's Issues

_test_free causes testcase to fail when called with ptr = 0

What steps will reproduce the problem?
1. Call _test_free with the first argument set to 0 or NULL
2. _test_free asserts that ptr must not be null
3. testcase fails

What is the expected output? What do you see instead?

Since calling free(0) is a no-op in standard C, cmockery should not behave
differently. 

What version of the product are you using? On what operating system?
cmockery-0.1.2 on windows XP using cygwin

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 1 Apr 2010 at 9:42

cmocka - the successor of cmockery

Hello,

as cmockey is unmaintained I've forked the project some years ago and created a successor called cmocka. You can find the project website here:

https://cmocka.org/

It would be great if you could point to cmocka which fixes a lot of bugs and has much more features than cmockery in the meantime.

Thanks,

Andreas

strsignal() function is on available on HP-UX IA64 v3

What steps will reproduce the problem?
1. compile any unit tests bundle and link it against cmockery

What is the expected output? What do you see instead?

Linking fails with the following error:

ld: Unsatisfied symbol "strsignal" in file cmockery.o

What version of the product are you using? On what operating system?

1. cmockery-0.1.2
2. HP-UX 11 IA64 v3

uname -a

HP-UX hpitv3 B.11.31 U ia64 0383467329 unlimited-user license

Please provide any additional information below.

The 'strsignal()' function is not available on HP-UX. The following is not a 
proper 
solution but the workaround. Using _HPUX macro allows to link successfully on 
HP-UX.

--- cmockery.c  Sat Aug 30 02:55:54 2008
+++ cmockery.c  Tue Jul 21 10:44:53 2009
@@ -1402,7 +1402,11 @@

 #ifndef _WIN32
 static void exception_handler(int sig) {
+#ifdef _HPUX
+   print_error("%d\n", sig);
+#else
    print_error("%s\n", strsignal(sig));
+#endif
    exit_test(1);
 }

Original issue reported on code.google.com by [email protected] on 21 Jul 2009 at 10:20

Source in sample code into Markdown docs automatically

Right now, README.md includes copy-pasted code from sample code in src/example/ tree, but they're not kept in-sync automatically.

Ideally, we would have a process for automatically including code samples, e.g., via some preprocessing since it's probably not possible to do it dynamically, so that we can avoid having to see them diverge, e.g., as can be seen in issue #28 and possibly others.

It will also ensure that the code remains valid, as it will be compiled when it's in the src/example directory, but we cannot compile or test code while it's in the README.md file.

Bug: assert_false is a copy of assert_true

Lines 1226 and 1236 of cmockery.c should not be the same. :)

Mock generated code runs failed on ARM

When I test a software whose code is based on cmockery. The software is greenplum database.
The genarated file is
~/src/gpdb$ vi src/test/unit/mock/backend/libpq/pqexpbuffer_mock.c

bool
appendPQExpBufferVA(PQExpBuffer str, const char * fmt, va_list args)
{
check_expected(str);
check_expected(fmt);
check_expected(args);
optional_assignment(fmt);
return (bool) mock();
}

I exec 'make -s unittest-check' amd get error.
../../../../../src/test/unit/mock/backend/libpq/pqexpbuffer_mock.c: In function 'appendPQExpBufferVA':
../../../../../src/test/unit/mock/backend/libpq/pqexpbuffer_mock.c:110:2: error: aggregate value used where an integer was expected
check_expected(args);
^~~~~~~~~~~~~~
: recipe for target '../../../../../src/test/unit/mock/backend/libpq/pqexpbuffer_mock.o' failed
make[4]: *** [../../../../../src/test/unit/mock/backend/libpq/pqexpbuffer_mock.o] Error 1
../../../../src/backend/common.mk:52: recipe for target 'unittest-check-local' failed
make[3]: *** [unittest-check-local] Error 2
../../../src/backend/common.mk:49: recipe for target 'unittest-check-dispatcher-recurse' failed
make[2]: *** [unittest-check-dispatcher-recurse] Error 2
common.mk:49: recipe for target 'unittest-check-cdb-recurse' failed
make[1]: *** [unittest-check-cdb-recurse] Error 2
GNUmakefile:173: recipe for target 'unittest-check' failed
make: *** [unittest-check] Error 2

I run this test on both X86 and ARM machines. So I guess it might be different on these different ARCH.

Any idea to fix it? Thanks

Release 0.1.3 to address issues in 0.1.2

0.1.2 has a known issue with MacOS, which was reported in issue #3 and exemplified in the Homebrew config.

We should (finally) release 0.1.3 to enable us to cleanup the patch in Homebrew and enable everyone to avoid manual workarounds for this issue.

Note: this should be done after we re-create the historical versions as per issue #61.

free_symbol_map_value casts pointer to smaller integral type on LP64 platforms

What steps will reproduce the problem?
1. Compile on LP64 platform such as Mac OS X or Linux on x86_64
2. Observed compiler warning messages.

What is the expected output? 

No warnings.

What do you see instead?

/Users/smb/src/cmockery-staging/osx/../src/cmockery.c: In function 
'free_symbol_map_value':
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:474: warning: cast from 
pointer to 
integer of different size
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:478: warning: cast to 
pointer from 
integer of different size


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 1:48

a warning-clean patch based on svn r.42

What steps will reproduce the problem?

1. gcc/g++ warns when compiling cmockery.c with some options such as -Wall


What is the expected output? What do you see instead?

no output

What version of the product are you using? On what operating system?

version: svn r.42
system: Windows XP SP3
compiler: gcc 3/4 and g++3/4 in mingw

Please provide any additional information below.

with this patch, we clean the warnings when
  gcc -c -std=c99 -O6 -Os -Wall -Wextra -Werror -pedantic
  g++ -c          -O6 -Os -Wall -Wextra -Werror

Original issue reported on code.google.com by [email protected] on 25 Nov 2009 at 6:44

Attachments:

• warning-clean.patch

stdout and stderr outputs could be messed up

What steps will reproduce the problem?
1. compile the standard cmockery example 'assert_macro_test.exe' on Windows
2. execute "assert_macro_test.exe 1>output 2>&1"

What is the expected output? What do you see instead?

The file "output" should contain:

get_status_code_string_test: Starting test
"Connection dropped" != "Connection timed out"
ERROR: ..\src\example\assert_macro_test.c:29 Failure!
get_status_code_string_test: Test failed.
string_to_status_code_test: Starting test
0x2 != 0x1
ERROR: ..\src\example\assert_macro_test.c:35 Failure!
string_to_status_code_test: Test failed.
2 out of 2 tests failed!
    get_status_code_string_test
    string_to_status_code_test

but it contains:

get_status_code_string_test: Starting test
get_status_code_string_test: Test failed.
string_to_status_code_test: Starting test
string_to_status_code_test: Test failed.
"Connection dropped" != "Connection timed out"
ERROR: ..\src\example\assert_macro_test.c:29 Failure!
0x2 != 0x1
ERROR: ..\src\example\assert_macro_test.c:35 Failure!
2 out of 2 tests failed!
    get_status_code_string_test
    string_to_status_code_test

What version of the product are you using? On what operating system?

1. cmockery 0.1.2
2. Windows XP SP3
3. Visual Studio 2008

Please provide any additional information below.

fflush() function should be called after each line printed to the stdout or 
stderr.

The patch below fixes this problem:

--- cmockery.c  Sat Aug 30 02:55:54 2008
+++ cmockery.c  Tue Jul 21 10:24:14 2009
@@ -1449,6 +1449,7 @@
    char buffer[1024];
    vsnprintf(buffer, sizeof(buffer), format, args);
    printf(buffer);
+   fflush(stdout);
 #ifdef _WIN32
    OutputDebugString(buffer);
 #endif // _WIN32
@@ -1459,6 +1460,7 @@
    char buffer[1024];
    vsnprintf(buffer, sizeof(buffer), format, args);
    fprintf(stderr, buffer);
+   fflush(stderr);
 #ifdef _WIN32
    OutputDebugString(buffer);
 #endif // _WIN32

Original issue reported on code.google.com by [email protected] on 21 Jul 2009 at 10:39

index.html fail_connect_to_customer_database() code doesn't match example source

What steps will reproduce the problem?
1. Open http://cmockery.googlecode.com/svn/trunk/doc/index.html#Mock_Functions 
2. Observe the fail_connect_to_customer_database() source and note that it 
won't fail as the comment explains, because it includes a will_return() call
3. Compare that to 
http://code.google.com/p/cmockery/source/browse/trunk/src/example/customer_datab
ase_test.c?r=42, which doesn't include the will_return() call

What version of the product are you using? 
0.1.2


Index: index.html
===================================================================
--- index.html  (revision 42)
+++ index.html  (working copy)
@@ -466,7 +466,6 @@
 /* This test fails as the mock function connect_to_database() will have no
  * value to return. */
 void fail_connect_to_customer_database(void **state) {
-    will_return(connect_to_database, 0x0DA7ABA53);
     assert_true(connect_to_customer_database() ==
                 (DatabaseConnection*)0x0DA7ABA53);
 }

Original issue reported on code.google.com by [email protected] on 4 Jan 2011 at 7:14

Not warnings-clean on 64-bit SuSE 9.4

Built on AMD64 SuSE 9.4, 75 warnings generated (make stderr attached)

> uname -a
Linux lx3-kdb-sng 2.6.5-7.312-smp #1 SMP Fri Jun 6 13:44:33 UTC 2008 x86_64
x86_64 x86_64 GNU/Linux
> cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 4

Original issue reported on code.google.com by [email protected] on 16 Sep 2008 at 3:18

Attachments:

• make.err

char* to int conversion truncation warning on HP-UX in 64-bit mode

What steps will reproduce the problem?
1. execute "cc +DD64 -c -I../include cmockery.c"

What is the expected output? What do you see instead?

Nothing should be printed but it says:

"cmockery.c", line 1657: warning #2069-D: integer conversion resulted in
          truncation
                                assert_false("BUG: shouldn't be here!");

What version of the product are you using? On what operating system?

1. cmockery-0.1.2
2. HP-UX 11 IA64 v3

uname -a

HP-UX hpitv3 B.11.31 U ia64 0383467329 unlimited-user license

cc --version

cc: HP C/aC++ B3910B A.06.22 [Nov 14 2008]

Please provide any additional information below.

The statement causing the warning should be fixed anyway. The patch below 
does it as the HP-UX workaround:

--- cmockery.c  Sat Aug 30 02:55:53 2008
+++ cmockery.c  Tue Jul 21 10:46:56 2009
@@ -1650,7 +1650,9 @@
                }
                break;
            default:
+#ifdef _HPUX
                assert_false("BUG: shouldn't be here!");
+#endif
                break;
            }

Using _HPUX macro allows to compile on HP-UX without this warning.

Original issue reported on code.google.com by [email protected] on 21 Jul 2009 at 10:31

Fix build after removing stale files

Turns out that the stale docs files removed in PR #50 are actually involved in the build, and without them, the build breaks: https://travis-ci.org/google/cmockery/builds/500010453 which ends with:

gcc -g -O2 -o .libs/run_tests run_tests-run_tests.o  ./.libs/libcmockery.so
creating run_tests
make: *** No rule to make target 'doc/index.html', needed by 'all-am'.  Stop.
The command "./configure && make" exited with 2.

Integer conversion warning on HP-UX

What steps will reproduce the problem on HP-UX?
1. execute "cc -c -I../include cmockery.c"

What is the expected output? What do you see instead?

Nothing should be printed. But it says:

"cmockery.c", line 1679: warning #2068-D: integer conversion resulted in a
          change of sign
                total_failed = -1;
                               ^

What version of the product are you using? On what operating system?

1. cmockery 0.1.2
2. HP-UX IA64

uname -a

HP-UX hpitv3 B.11.31 U ia64 0383467329 unlimited-user license

Please provide any additional information below.

Following patch removes this warning:

--- cmockery.c  Sat Aug 30 02:55:54 2008
+++ cmockery.c  Tue Jul 21 11:00:53 2009
@@ -1670,7 +1670,7 @@
    if (number_of_test_states) {
        print_error("Mismatched number of setup %d and teardown %d 
"
                    "functions\n", setups, teardowns);
-       total_failed = -1;
+       total_failed = (size_t)-1;
    }

    free(test_states);

Original issue reported on code.google.com by [email protected] on 21 Jul 2009 at 10:13

no vsvars.bat for windows build

release-0.1.2 there is not a vsvars.bat scripts for windows build

malloc size overflow

_test_malloc ironically suffers from a painfully obvious size_t overflow when calculating allocate_size. a simple assert_true(allocate_size > size) should fix this.

is this project active?

Hello, is this project active or dead? is the community still support it? I'd like to use it in our project.

value_in_set_display_error() falsely reports errors.

When I call assert_in_set() with a value of '1' and an enumeration array as the 
set (0-12), I get the 
following error:
"1 is not in the set (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, )"

Calling assert_in_set() will call value_in_set_display_error() with invert=0.
It looks like there's something wrong with the "invert" logic.
As soon as set[i] == value (e.g. 1 == 1), the 'for' loop breaks, but
then rather than return success, it prints the error message and
returns failure.

Original issue reported on code.google.com by [email protected] on 9 Jan 2009 at 8:21

check_expected causes segfault.

What steps will reproduce the problem?
1. Compile test-cmockery with 
gcc -std=c99 -I/opt/include -L/opt/lib -lcmockery test-cmockery.c -o 
test-cmockery
2. Run ./test-cmockery

What is the expected output? What do you see instead?
Expected output:
sizeof(unsigned long long): 8
sizeof(unsigned): 4
sizeof(char*): 8
4365541014
70573718
70573718
4365541014
test_demo: Starting test
test_demo: Test completed successfully.
All 1 tests passed

Actual output:
sizeof(unsigned long long): 8
sizeof(unsigned): 4
sizeof(char*): 8
4438503062
143535766
143535766
4438503062
test_demo: Starting test
Segmentation fault: 11
test_demo: Test failed.
1 out of 1 tests failed!
    test_demo


What version of the product are you using? On what operating system?
Git commit: 1c63f1f479463d9cb5185681cf11799e8efa9092
on Macintosh OS X Mountain Lion 10.8.5

Please provide any additional information below.
By modifying the macro cast_to_largest_integral_type (cmockery.h, line 51), it 
is possible to to remove the error and see the expected output. Specifically, 
changing
#define cast_to_largest_integral_type(value)    \
    ((LargestIntegralType)((unsigned)(value))) 
to 
#define cast_to_largest_integral_type(value)                    \
    ((LargestIntegralType)((unsigned long long)(value)))
removes the error. What is the purpose of casting a pointer (8 bytes on my 
system), to an unsigned integer (4 bytes on my system), then back to an 
unsigned long long (8 bytes on my system)?

Original issue reported on code.google.com by [email protected] on 4 Jun 2014 at 8:25

Attachments:

• test-cmockery.c
• test-cmockery.out

COPYING appears to contradict actual license

COPYING[1] (incorrectly) indicates that cmockery is distributed under a BSD
license.

[1] http://code.google.com/p/cmockery/source/browse/trunk/COPYING

Original issue reported on code.google.com by [email protected] on 16 Nov 2009 at 10:36

Using will_return_count with count=-1 (to always repeat return value) results in assertion failure

What steps will reproduce the problem?
1. Use the macro 'will_return_count' with a count value of -1
2.
3.

What is the expected output? What do you see instead?
The documentation indicates that the specified value will always be
repeated when the count is -1.  When used, the first assertion in
_will_return fires.

>>>>
    assert_true(count > 0);

What version of the product are you using? On what operating system?
cmockery-0.1.2
Windows Vista/Linux

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 26 Oct 2008 at 7:03

gcc compiler warning: format not a string literal and no format arguments

What steps will reproduce the problem?
1. Compile cmockery using gcc version 4.2.1.
2. Observe warning messages.

What is the expected output? 

No warnings

What do you see instead?

/Users/smb/src/cmockery-staging/osx/../src/cmockery.c: In function 
'vprint_message':
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:1550: warning: format not 
a string 
literal and no format arguments
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c: In function 
'vprint_error':
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:1561: warning: format not 
a string 
literal and no format arguments


What version of the product are you using? On what operating system?

cmockery tip on Mac OS 10.6.2 using Xcode 3.2.1, also on CentOS 5.4 wtih gcc 
(GCC) 4.1.2 
20080704 (Red Hat 4.1.2-46)

Please provide any additional information below.

Trivially fixed by adding printf format string to the two printf and fprintf 
calls:

    printf("%s", buffer);

    fprintf(stderr, "%s", buffer);

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 7:03

Problem when mocking printf

What steps will reproduce the problem?

When testing a function, say "foo", that uses "printf", if I a 
mock "printf" using mock() and check_expected() and write a test 
for "foo", when executing the test, cmockery crashes (segfault). Here is a 
small snippet of code illustrating what I mean:

// foo.c
int foo() {
    return printf("toto");
}

// foo_test.c
int printf(const char *format, ...) {
    check_expected(format);
    return (int)mock();
}

void my_test(void **state) {
    expect_string(printf, format, "toto");
    will_return(printf, 30);
    assert_int_equal(foo(), 30);
}

When executing the test, the program segfaults. Here is the gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0804928b in list_find ()
(gdb) bt
#0  0x0804928b in list_find ()
#1  0x080495fb in get_symbol_value ()
#2  0x0804a6ff in _check_expected ()
#3  0x08048ce3 in printf ()
#4  0x0804aff0 in vprint_message ()
#5  0x0804b057 in print_message ()
#6  0x0804b106 in _run_test ()
#7  0x0804b3d1 in _run_tests ()
#8  0x08048db3 in main ()


What is the expected output? What do you see instead?

the test should pass (?)

What version of the product are you using? On what operating system?

cmockery 0.1.2 on linux (debian 4.1.1-21) with gcc 4.1.2

I attached the code provoking the buf...

Otherwise cmockery rules! ;-)

Thanks for looking into this!

Original issue reported on code.google.com by [email protected] on 15 Oct 2009 at 9:22

Attachments:

• cmockery-printf-bug.tgz

many portability issues in printf format specifiers

What steps will reproduce the problem?
1. create the following unit test of cmockery:

/***
* @unit_test assert_in_range with signed int.
*/
void test_assert_in_range_signed_int(void **state) {
    int value;
    int lower_bound;
    int upper_bound;
    value = INT_MIN;
    lower_bound = INT_MIN;
    upper_bound = INT_MAX;
    fprintf(stderr, "             lower bound: %d upper bound: %d \n", 
            lower_bound, upper_bound);
    assert_in_range(value, lower_bound, upper_bound);
    value = INT_MAX;
    assert_in_range(value, lower_bound, upper_bound);
    value = 0;
    assert_in_range(value, lower_bound, upper_bound);
}

2. Compile and run on i386
3. Observe output:
[ RUN      ] test_assert_in_range_signed_int
            lower bound: -2147483648 upper bound: 2147483647 
-2147483648 is not within the range 0--2147483648
ERROR: /Users/smb/src/cmockery-staging/osx/../src/unit_test/unit_test.c:235 
Failure!

Note that the bounds on the range are odd.

What is the expected output? What do you see instead?

Fixing the printf format specification string in 
integer_in_range_display_error() to reflect the 
actual size and type of the arguments (unsigned long longs) gives a better 
diagnosis of the 
problem. Changing the print_error() call to:

   print_error("%llu is not within the range %llu-%llu\n", value, range_min,
               range_max);

gives us this on i386:

[ RUN      ] test_assert_in_range_signed_int
            lower bound: -2147483648 upper bound: 2147483647 
2147483648 is not within the range 2147483648-2147483647
ERROR: /Users/smb/src/cmockery-staging/osx/../src/unit_test/unit_test.c:235 
Failure!

What version of the product are you using? On what operating system?


Please provide any additional information below.


There are many other cases beside the integer_in_range_display_error() function 
where the printf 
format specification assumes a non-portable size. Other examples include 
printing pointers and 
size_t.

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 1:23

Freeing memory allocated by realloc() throw's error

What steps will reproduce the problem?

Below steps throw's Guard block error which I expect it shouldn't.

void leak_memory() {
    int * temporary = (int*)realloc(NULL, sizeof(int));
    temporary = (int *) realloc (temporary, (10 * sizeof (int)));
    free (temporary);
}

What is the expected output? What do you see instead?

Expected :-
===========
Allocated memory by realloc function should be free'd and test case should 
pass.

Output Seen:-
=======================================================================
leak_memory_test: Starting test
Guard block of 0x00501120 size=0 allocated by :5247040 at 0x00501118 is 
corrupt
ERROR: src/example/allocate_module.c:33 Failure!
leak_memory_test: Test failed.
1 out of 1 tests failed!
    leak_memory_test
=======================================================================

What version of the product are you using? On what operating system?

Product version - 
=============

cmockery-0.1.2

Operating System -
====================

ukhml-bladeAS4-~/mywork/cmockery-0.1.2/src/example: uname -a
Linux ukhml-bladeAS4 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 
2009 x86_64 x86_64 x86_64 GNU/Linux
ukhml-bladeAS4-~/mywork/cmockery-0.1.2/src/example:

====================

Please provide any additional information below.

In my actual unit test case, program flow calls these below functions in 
sequence which result in guard block error - 
step 
1.) malloc 
2.) realloc and 
3.) free. 
Only work around I could do was just replace all such calls to 
corresponding calls of realloc function for initial request to memory, re-
sizing memory and for freeing memory which overcame this error.
I was not able to re-produce with this sequence in an independent program. 
Instead a sequence of realloc and free helped in reproducing this error 
message which I mentioned above.
Is it something that realloc is not monitored by comockery ?

Thanks & Regards.,
Naveen Sriram.

Original issue reported on code.google.com by [email protected] on 22 Mar 2010 at 1:42

malloc.h not found on Mac OS Leopard

What steps will reproduce the problem?
1. Compile cmockery on Mac OS Leopard

What is the expected output? What do you see instead?
When running "./configure && make", it errors out saying that "malloc.h" can 
not be found (log 
attached as "plain-configure.log"). On Mac OS there are at least 3 different 
"malloc.h" files:

$ find /usr/include -name "malloc.h"
/usr/include/malloc/malloc.h
/usr/include/objc/malloc.h
/usr/include/sys/malloc.h

 Apparently "/usr/include/sys/malloc.h" is the one to use. Thus I attempted to compile cmockery 
by issueing the following command:

"CFLAGS="-I/usr/include/sys" ./configure && make

That got me further, but size_t does not appear to be defined.
According to stdlib.h, size_t is defined as:
typedef __darwin_size_t size_t;

Output of the build process is attached as "cflags-configure.log".

What version of the product are you using? On what operating system?
cmockery 0.1.2, Mac OS Leopard (10.5.4)

Original issue reported on code.google.com by [email protected] on 14 Oct 2008 at 1:00

Attachments:

• plain-configure.log
• cflags-configure.log

mock_assert attempts to pass pointer through longjmp int argument on LP64 platforms

What steps will reproduce the problem?
1. Compile on LP64 platform such as Mac OS X or Linux on x86_64
2. Observe warning messages.

What is the expected output? 

No warnings.

What do you see instead?

/Users/smb/src/cmockery-staging/osx/../src/cmockery.c: In function 
'mock_assert':
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:1232: warning: cast from 
pointer to 
integer of different size


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 1:51

Re-create historical releases (0.1.0, 0.1.1, 0.1.2) on GitHub

We can see the past release history in the ChangeLog:

Mon Sep 15 17:21:22 2008 Google Inc. <[email protected]>
	* cmockery: version 0.12
	* Made it possible to specify additional compiler, lib tool and link 
	flags on Windows.
	* Added Windows makefile to the tar ball.

Fri Aug 29 10:50:46 2008  Google Inc. <[email protected]>

	* cmockery: version 0.11
	* Made it possible to specify executable, library and object output 
	  directories.

Tue Aug 26 10:18:02 2008  Google Inc. <[email protected]>

	* cmockery: initial release:
	  A lightweight library to simplify and generalize the process of 
	  writing unit tests for C applications.

We just need to find the right commits that were the cut-offs for each of the release, and create an appropriate release tag for each of those points.

For v0.1.2, since that was the last release, we also have a pointer to the full tarball courtesy of Homebrew which is hosted on GCS which can be used to identify the right commit point.

Interestingly enough, git log also shows the release tags added to the repo in SVN, but there are several such commits for every SVN tag. We can also look at the commit history of the ChangeLog itself to identify the release points.

mock_assert attempts to pass pointer via int argument to longjmp

What steps will reproduce the problem?
1. Compile and execute assert_module_test.c on LP64 platform.
2. Observe crash in setjmp.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Fix by replacing the passing of the assert expression in the longjmp argument 
with passing the 
expression in a member of a volatile global structure.

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 5:48

assert_macro.c

Line30:

for (i = 0; i < sizeof(status_code_string) / sizeof(status_code_string[0]);    

change it as follow:

for (i = 0; i < sizeof(status_code_strings) / sizeof(status_code_strings[0]);

Original issue reported on code.google.com by khb.hnu on 12 Apr 2009 at 2:00

Problem in running test

My  application is written in ProC which is having many .pc files
I have only a Makefile to compile all this .pc files...We dont have
.configure or any other libtool files.
So i added one more line in my Makefile to create a test exe for
run_tests.c by including libcmockery.la 
but while compiling its giving link error as following
cc   -o Test  -L/usr/oracle/product/9.2.0_client/lib/  -DUNIT_TESTING=1 -o
./test run_tests.c    -L../../mdi_lib/ -lMDI_dyn_proc
../../mdi_lib/MDI_lib.a
/confman/rcs_wa/ccbs/LIBRARIES/lib/OSF1_V5.1/lib//libcommon.a -lclntsh `cat
/usr/oracle/product/9.2.0_client/lib/ldflags`   `cat
/usr/oracle/product/9.2.0_client/lib/sysliblist`  -lm  -lpthread
ld:
Unresolved:
_run_tests
make: *** [Test] Error 1

when i tried to run the test its giving me below problem
./test
resolve_symbols: loader error: dlopen: ./test: symbol "_run_tests" unresolved


what should i change in my Makefile?

Original issue reported on code.google.com by [email protected] on 4 Feb 2010 at 7:12

IsDebuggerPresent() function is not declared in Visual Studion 2005 and lower

What steps will reproduce the problem?

1. Create the simple test first_test.c:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include "cmockery.h"

void main(void) {}

2. Put cmockery.h and cmockery.c to the same directory
3. Compile it: cl /I. first_test.c cmockery.c

What is the expected output? What do you see instead?

Visual Studio 2003:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

first_test.c
cmockery.c
Generating Code...
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:first_test.exe
first_test.obj
cmockery.obj
cmockery.obj : error LNK2019: unresolved external symbol IsDebuggerPresent
referenced in function __run_test
first_test.exe : fatal error LNK1120: 1 unresolved externals


Visual Studio 2005:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

first_test.c
cmockery.c
Generating Code...
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:first_test.exe
first_test.obj
cmockery.obj
cmockery.obj : error LNK2019: unresolved external symbol _IsDebuggerPresent
refe
renced in function __run_test
first_test.exe : fatal error LNK1120: 1 unresolved externals


Visual Studio 2008:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

first_test.c
cmockery.c
Generating Code...
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:first_test.exe
first_test.obj
cmockery.obj

What version of the product are you using? On what operating system?

- cmockery 0.1.2
- Visual Studio 2003, 2005 SP1, 2008
- Windows XP SP3

Please provide any additional information below.

Conclusion: Only starting from Visual Studio 2008 the function
IsDebuggerPresent() is declared in headers.

I use the following patch which explicitly declares the function
IsDebuggerPresent() for Visual Studio 2005 and lower:

--- a/cmockery.h    Sat Dec 13 17:39:25 2008
+++ b/cmockery.h    Sat Dec 13 19:07:44 2008
@@ -15,19 +15,6 @@
  */
 #ifndef CMOCKERY_H_
 #define CMOCKERY_H_
-
-#ifdef _WIN32
-#if _MSC_VER < 1500
-#ifdef __cplusplus
-extern "C" {
-#endif
-int __stdcall IsDebuggerPresent();
-#ifdef __cplusplus
-} /* extern "C" */
-#endif
-#endif
-#endif
-
 /*
  * These headers or their equivalents should be included prior to including
  * this header file.

Original issue reported on code.google.com by [email protected] on 13 Dec 2008 at 7:41

[PATCH] Support for "out of source-tree" builds

Below is a patch to allow building of cmockery outside of the source
directory. 

It has been tested against subversion trunk, and passes 'make distcheck'.

Signed-off-by: Chris Heller <[email protected]>

--- cmockery-20081023/Makefile.am       2008-10-23 23:31:02.000000000 -0400
+++ cmockery-out-of-source-tree/Makefile.am     2008-10-23
23:32:28.000000000 -0400
@@ -46,13 +46,13 @@

 lib_LTLIBRARIES += libcmockery.la
 libcmockery_la_SOURCES = src/config.h src/cmockery.c src/google/cmockery.h
-libcmockery_la_CFLAGS = -Isrc/google
+libcmockery_la_CFLAGS = -I$(top_srcdir)/src/google

 noinst_PROGRAMS = calculator
 calculator_SOURCES = src/example/calculator.c src/config.h
 calculator_CFLAGS =

-unit_test_CFLAGS = -Isrc/google -Isrc/example -DUNIT_TESTING=1
+unit_test_CFLAGS = -I$(top_srcdir)/src/google -I$(top_srcdir)/src/example
-DUNIT_TESTING=1

 noinst_PROGRAMS += calculator_test
 calculator_test_SOURCES = src/example/calculator_test.c \

Original issue reported on code.google.com by [email protected] on 24 Oct 2008 at 3:54

cast_to_largest_integral_type truncate a 64bit value to 32bit

When I try to call will_return with a pointer paremeter on a 64bit linux platform. mock fucntion return another value which losses the high 32bit of the origin value.
int customer_ids = 543; will_return(mock_query_database, &customer_ids);
*results = (void**)mock();
&customer_ids = 0x7ffe38d150cc
but mock() = 0x38d150cc

finally, I modify the source code in cmockery.h, remove ‘unsiged’ in
#define cast_to_largest_integral_type(value) \ ((LargestIntegralType)((unsigned)value))
it works.

Please archive this project

I have the unfortunate responsibility of maintaining a legacy project that uses cmockery as a unit testing framework. The tests were broken and ignored for years, when I finally did the effort to got them working again, I quickly started hitting my head on issues like long long / uint64_t types not being supported (#2 !?) and basic stuff like assert_false not working (#70).

Please, mark this project as archived and point people towards actual functional and maintained C unit testing frameworks like Unity, Cgreen, Cpputest or Googletest. Having the Google name associated to this project might trick some people into thinking it's a well designed and usefull project, but as soon as you start using it for even the most basic use-cases, the opposite quickly becomes apparent.

On top of that, the mailing list is full of spam.

allocate_module_test fails

When trying to run allocate_module_test, it fails. Is this the expected
output? Are other tests expected to fail?

$ ./allocate_module_test
leak_memory_test: Starting test
Blocks allocated...
  0x0804a0c8 : src/example/allocate_module.c:30
ERROR: leak_memory_test leaked 1 block(s)
leak_memory_test: Test failed.
buffer_overflow_test: Starting test
Guard block of 0x0804a100 size=4 allocated by
src/example/allocate_module.c:35 a t 0x0804a104 is corrupt
ERROR: src/example/allocate_module.c:37 Failure!
buffer_overflow_test: Test failed.
buffer_underflow_test: Starting test
Guard block of 0x0804a150 size=4 allocated by
src/example/allocate_module.c:41 a t 0x0804a14f is corrupt
ERROR: src/example/allocate_module.c:43 Failure!
buffer_underflow_test: Test failed.
3 out of 3 tests failed!
    leak_memory_test
    buffer_overflow_test
    buffer_underflow_test
Blocks allocated...
  0x0804a0c8 : src/example/allocate_module.c:35
  0x0804a118 : src/example/allocate_module.c:41
Guard block of 0x0804a100 size=4 allocated by
src/example/allocate_module.c:35 a t 0x0804a104 is corrupt
ERROR: src/cmockery.c:1379 Failure!

What steps will reproduce the problem?
1. ./configure
2. make
3. ./allocate_module_test

What is the expected output? What do you see instead?

I expected no test failures. If this is an expected failure, that'd be
great to know.


What version of the product are you using? On what operating system?

This is on debian 4.1 with the following gcc -v

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Please provide any additional information below.
I have a port of cmocker to OS X that fails in this same way.

Original issue reported on code.google.com by [email protected] on 28 Jan 2009 at 5:25

Add headers for regular case

Hi!

I think adding the standard required headers within #if/#endif would reduce
the code needed to bootstrap a new test.

#ifndef CMOCKERY_NO_STANDARD_HEADERS
#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#endif

Original issue reported on code.google.com by tommie%[email protected] on 18 Aug 2009 at 7:24

Doing a mockup of a function which have a long long (>32 bits) parameter

Hi !

If you have a function with "long long" parameters/return value, like this
one :
int myFunction(long long id, char *name);

If I try to do a mockup with this function :

int myFunction(long long id, char *name) {
  check_expected(id);
  check_expected(name);
  return *(int *)mock();
}

First, the computer will warn me "warning: cast to pointer from integer of
different size". The line "check_expected(id);" seems to trig the problem.

In fact the macro cast its parameter to a "void *", but a "void *" is a 32
bits wide and the "id" parameter is 64 bits wide.

I can ignore the warning and continue with it, but the checked value will
be truncated, the test will be a success, if I do someting like :

...
expect_value(myFunction, id, 0x34FFFFFFFF);
...
myFunction(0x89FFFFFFFF, "hello");
...

What is your opinion on it ?


Would it be easy to cast the "value" parameter to the biggest type
available on the current host (long long ?) ?
Or will it break something ?


Thanks for your help and for this amazing tool : mockup in c is a really
cool feature !

Original issue reported on code.google.com by [email protected] on 7 Oct 2008 at 9:02

Delete extra files and branches with duplicate docs

On the master branch, in the doc top-level directory, there are the following files:

• html2wiki.sh
• index.html

The index.html file appears to have the same content as the top-level README.md file and we should be able to delete it, and the script was only useful for Google Code, so it can go as well.

On the wiki branch, we have the following top-level files:

• ProjectHome.md: a summary of the project, which already appears in the current top-level README.md
• cmockery.md: appears to be the same content as README.md, but with some errors in the Markdown formatting

I propose deleting both of the files in the doc directory, as well as both of the files on the wiki branch, which also implies removing the doc directory itself, and deleting the wiki branch itself, as there are no other files remaining in either once we do this cleanup.

@stewartmiles, are you OK with all of the proposed changes above? If so, I'm happy to do them.

_test_free() casts pointer to int on LP64 platforms

What steps will reproduce the problem?
1. Compile on LP64 platform.
2. Observe gcc warning messages.

What is the expected output? 

No warnings.

What do you see instead?

/Users/smb/src/cmockery-staging/osx/../src/cmockery.c: In function '_test_free':
/Users/smb/src/cmockery-staging/osx/../src/cmockery.c:1405: warning: cast from 
pointer to 
integer of different size



What version of the product are you using? On what operating system?


Please provide any additional information below.

Problem is statement:

_assert_true((int)ptr, "ptr", file, line);

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 1:54

Some warnings related with printf and derivates.

I've noticed some warnings related with an "incorrect" use of printf and
derivates. Could you fix that issue aplying the next patch?

1535c1535
<     puts(buffer);

---
>     printf(buffer);
1545c1545
<     fputs(buffer, stderr);

---
>     fprintf(stderr, buffer);

Original issue reported on code.google.com by [email protected] on 7 Mar 2010 at 2:39

can not find vsvars.bat

1 when i clone project
2 execute like readme in windows
3 can not fund vsvars.bat,
is it a problem?