by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 29 16:53
    LeandreBl edited #353
  • May 29 16:53
    LeandreBl edited #353
  • May 29 16:51
    LeandreBl opened #353
  • May 29 15:32
    LeandreBl edited #352
  • May 29 15:32
    LeandreBl edited #352
  • May 29 15:27
    LeandreBl opened #352
  • May 29 14:54
    LeandreBl commented #351
  • May 29 14:28
    LeandreBl commented #351
  • May 29 14:28
    LeandreBl synchronize #351
  • May 29 14:26
    LeandreBl commented #351
  • May 29 13:22
    LeandreBl synchronize #351
  • May 29 13:13
    LeandreBl synchronize #351
  • May 29 12:43
    LeandreBl commented #351
  • May 29 12:31
    LeandreBl synchronize #351
  • May 29 12:25
    LeandreBl commented #351
  • May 29 12:24
    LeandreBl commented #351
  • May 29 12:22
    LeandreBl opened #351
  • May 29 12:05
    LeandreBl commented #314
  • May 29 12:03
    LeandreBl commented #314
  • May 29 11:51
    LeandreBl commented #314
Dominik
@kaidowei
I guess, we could make both work together
Franklin Mathieu
@Snaipe
that could be counterproductive
Dominik
@kaidowei
well, both have limitations
the second works for ... functions
Franklin Mathieu
@Snaipe
right, variadics work out of the box here
however the handling of void-returning functions is moved to mmk_expect
since mmk_expect takes in a hard value to return
you'd need to have a mmk_expect and mmk_expect_and_return
or something of that flavor
I guess, to be fair, that there could be some convenience functions of the sort for the stub API rather than the mock API
you could also decouple the return value from mmk_expect
Franklin Mathieu
@Snaipe
which means you'd have
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(ptr == NULL && size == 42);
    mmk_return(NULL);
    mmk_expect(ptr == (void*) -1);
    mmk_return(NULL);
    for (size_t i = 0; i < 10; ++i) {
        mmk_expect(size == i);
        mmk_return(NULL);
    }
    mmk_mock_end;
}
this fixes the problem of the void-returning function handling
but it also a whole lot more verbose
Dominik
@kaidowei
hmm that seems a bit overkill
Franklin Mathieu
@Snaipe
I'm not that much of a fan, yeah
Dominik
@kaidowei
mmk_expect and mmk_expect_return and mmk_return should be enough
the compiler will see some return foo for a return void function and complain
Dominik
@kaidowei
@Snaipe are you interested in memory leaks for criterion v2.2.0?
Franklin Mathieu
@Snaipe
sure, what do you have ?
Dominik
@kaidowei
{
   criterion redirect pipe
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_*
}
Franklin Mathieu
@Snaipe
where is this happenning?
Dominik
@kaidowei
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:alloc_entry
   fun:smalloc_impl
   fun:smalloc
   fun:test_stats_init
   fun:run_next_test
   fun:run_tests_async
   fun:criterion_run_all_tests_impl
   fun:criterion_run_all_tests
   fun:main
}
Franklin Mathieu
@Snaipe
oh, wait, it's a suppression
Dominik
@kaidowei
yeah
I can send you the stacktrace/code too
Franklin Mathieu
@Snaipe
I would rather, cr_get_redirected_* isn't really helpful
I think the second leak has been fixed on patch
Dominik
@kaidowei
==743== 568 bytes in 1 blocks are still reachable in loss record 2 of 2
==743==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==743==    by 0x50C2D41: fdopen@@GLIBC_2.2.5 (iofdopen.c:138)
==743==    by 0x4E42713: pipe_in (pipe.c:46)
==743==    by 0x4E43B00: cr_get_redirected_stderr (redirect.c:62)
==743==    by 0x401FDA: another_suite_test_stdout_impl (test_all.c:44)
==743==    by 0x4E425C5: criterion_internal_test_main (test.c:56)
==743==    by 0x4016EA: another_suite_test_stdout_jmp (test_all.c:37)
==743==    by 0x4E3F6F8: run_test_child (runner.c:180)
==743==    by 0x4E41808: run_worker (worker.c:84)
==743==    by 0x4E4193C: spawn_test_worker (worker.c:111)
==743==    by 0x4E40FCE: run_test (runner_coroutine.c:66)
==743==    by 0x4E41506: run_next_test (runner_coroutine.c:162)
==743== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_stderr
   fun:another_suite_test_stdout_impl
   fun:criterion_internal_test_main
   fun:another_suite_test_stdout_jmp
   fun:run_test_child
   fun:run_worker
   fun:spawn_test_worker
   fun:run_test
   fun:run_next_test
}
arg
Franklin Mathieu
@Snaipe
oh, right
Dominik
@kaidowei
static void redirect_all_std(void) {
    cr_redirect_stdout();
    cr_redirect_stderr();
}

Test(another_suite, test_stdout, .init = redirect_all_std) {
    fprintf(stdout, "foo");
    fflush(stdout);
    cr_assert_stdout_eq_str("foo");

    fprintf(stderr, "bar");
    fflush(stderr);
    cr_assert_stderr_eq_str("bar");
}
and the other one....
Franklin Mathieu
@Snaipe
I think I forgot to close both file handles, so it's (kinda) normal
and yeah, 2nd memleak has been fixed on bleeding
Dominik
@kaidowei
ah okay. But I guess we will not switch to bleeding :D
Franklin Mathieu
@Snaipe
yeah, not yet though
I'll cherry pick the fix on the patch branch
Dominik
@kaidowei
thanks
plans for 2.2.1?
Franklin Mathieu
@Snaipe
2.2.1 will be released this saturday if everything goes right
Franklin Mathieu
@Snaipe
@kaidowei I experimented a bit more with the 1rst API draft and came up with this: http://pastebin.com/raw/dkCKD4YY
This possible 2nd draft should be more adequate than the first for mocking
(the syntax is inspired by mockito)
I haven't got the time to really make a full implementation, but it seems to be possible from the few tests I ran
I am also hesitating on the syntax of mmk_when

there's

mmk_when (malloc, m,
            .with_size = mmk_eq(size_t, sizeof (ref)),
            .then_return = buf);

of course, but

mmk_when (m, malloc(sizeof (ref)), .then_return = buf);

seems really attractive

The biggest obstacle against syntax 2 are sequence points
Franklin Mathieu
@Snaipe
but I think I might be able to bypass it with some macro magic and __COUNTER__.
this also opens the door to over the top control over parameter conditions