by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:44
    ijustlovemath opened #349
  • 14:08
    COLAMAroro commented #342
  • Apr 19 12:07
    Breigner01 commented #348
  • Apr 19 12:07
    Breigner01 closed #348
  • Apr 19 12:07
    Breigner01 commented #348
  • Apr 18 21:48
    Breigner01 edited #348
  • Apr 18 21:46
    Breigner01 opened #348
  • Apr 09 13:01

    Snaipe on bleeding

    meson: add option to disable di… (compare)

  • Apr 09 13:01
    Snaipe closed #344
  • Apr 09 13:01
    Snaipe commented #344
  • Apr 06 14:23
    tsieprawski commented #344
  • Apr 06 14:23
    tsieprawski commented #344
  • Apr 06 14:04
    tsieprawski synchronize #344
  • Apr 06 13:32
    tsieprawski synchronize #344
  • Apr 06 13:30
    tsieprawski synchronize #344
  • Apr 06 12:55
    tsieprawski synchronize #344
  • Apr 06 12:29
    tsieprawski commented #344
  • Apr 06 11:06
    lgutter commented #345
  • Apr 05 13:42
    Snaipe edited #321
  • Apr 05 13:29
    Snaipe closed #343
Franklin Mathieu
@Snaipe
in terms of line, it's about the same to be honest, you still have to do it somewhere
whenever it's inside a function or your test isn't that much important
Dominik
@kaidowei
yes, the generate thing was meant for the current approach
Franklin Mathieu
@Snaipe
the big plus here is that this API is lightweight, and you don't need to do some massive hacking with offsets to compare actual and expected values
you simply pass a predicate that references the parameters
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