Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 24 14:27
    lazy-dude opened #390
  • Sep 24 13:44
    lazy-dude opened #389
  • Sep 22 21:14
    hl037 opened #388
  • Sep 12 03:11
    2LeoCode closed #387
  • Sep 12 02:47
    2LeoCode opened #387
  • Sep 04 11:29
    Noman5237 closed #385
  • Sep 02 21:17
    Noman5237 closed #386
  • Sep 02 21:17
    Noman5237 commented #386
  • Sep 02 20:49
    Noman5237 opened #386
  • Sep 02 20:39
    Noman5237 opened #385
  • Sep 02 11:18
    talentless-script-kiddie commented #229
  • Sep 02 11:00
    talentless-script-kiddie commented #229
  • Aug 26 16:36
    junglie85 opened #384
  • Aug 24 23:49
    CamJN commented #383
  • Aug 24 03:23
    CamJN opened #383
  • Aug 20 17:09
    CamJN opened #382
  • Aug 10 22:55
    margaretdax commented #212
  • Aug 05 12:33
    cacharle closed #381
  • Aug 05 12:31
    cacharle edited #381
  • Aug 05 12:30
    cacharle commented #381
Dominik
@kaidowei
und ignore_all sets that for the whole array
btw... I'm busy this evening & tomorrow. (except for work :D) do you want to test this out?
Franklin Mathieu
@Snaipe
I'm currently setting up travis builds, I'll experiment with that on my end after this
Dominik
@kaidowei
okay
but this is good progress :)
Franklin Mathieu
@Snaipe
Haha, yes, but we still have a long way to go
Dominik
@kaidowei
haven't thought about mocking functions, that contain varargs
Franklin Mathieu
@Snaipe
That's also an issue
we'll probably have to provide functions to build a va_list structure per platform
then pass it to a special .va_args parameter
Dominik
@kaidowei
let future us deal with that ;)
Franklin Mathieu
@Snaipe
yeah, that's going to be a pain though
Dominik
@kaidowei
I'm not sure, other frameworks support that
and the callback approach will work
Dominik
@kaidowei
@Snaipe hi, we're you able to implement the things we talked about?
Franklin Mathieu
@Snaipe
I actually did some huge progress
not specifying fields also works like a charm
which means that mmk_expect(foo, .param = 0) still expects 0 for param, and mmk_expect(foo) would accept any param
Dominik
@kaidowei
wow, how did you solve that?
Franklin Mathieu
@Snaipe
parsing, mostly
I stringify the parameters to see what gets passed
Dominik
@kaidowei
:D
Franklin Mathieu
@Snaipe
and initialize an offset table into the structure to match names with fields
Dominik
@kaidowei
I find it counter intuitive, that you write mmk_mock_define (realloc_mock, void *, void *, ptr, size_t, size); to mock realloc
Franklin Mathieu
@Snaipe
It was to prepare for harminization with other macros
I would expect mmk_mock* macros to first pass the identifier of the mock stub
but you could use a c-style declaration order, yeah
given the documentation, would you really find that counterintuitive?
Also, you still have to discriminate with the case where void is the return type
(as you can't have void as a structure field)
so both mmk_mock_define and mmk_mock_define_void share the same ordering logic
Dominik
@kaidowei
well, I'm not talking about void *, realloc_mock vs. realloc_mock, void *but about realloc_mock
sorry for the confusion
the _mock
Franklin Mathieu
@Snaipe
oh, right
this will probably get changed in proper samples
it's just a name though, so we're free to choose
Dominik
@kaidowei
ah, I thought, that if we set the name there, we don't have to do that at the create time
Franklin Mathieu
@Snaipe
that would be against reusability
Dominik
@kaidowei
why is that?
Franklin Mathieu
@Snaipe
actually, let me rephrase that
you need to specify the name because you need some kind of ID to refer to the declared structures, and even if you found a way to do so without, you could still want to be able to declare a mock prototype for a group of functions sharing the same prototype
mmk_mock_define defines a model, not a targetted mock
Dominik
@kaidowei
I'm not convinced, that it is useful to reuse a defined mock multiple times
that only works for a group of functions, that share the same signature
Franklin Mathieu
@Snaipe
why not? The behaviour of the mock stub is exactly the same
Dominik
@kaidowei
yes, but they could stand for VERY different things.
I would not use the same definition for compare(obj1, obj2) and merge(obj1, obj2)
Franklin Mathieu
@Snaipe
I'm mostly talking about functions made to respect a particular function pointer definition