Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 24 20:45
    RaniAgus edited #380
  • May 24 20:44
    RaniAgus opened #380
  • May 07 13:26
    MrAnno commented #301
  • May 07 13:08
    hydrapolic commented #336
  • Mar 22 16:33
    mabati opened #379
  • Mar 15 09:24
    JolanBrizard opened #378
  • Mar 06 19:58
    mochrul opened #377
  • Mar 05 19:58
    vzuevsky commented #248
  • Feb 19 16:41
    SDAChess commented #376
  • Feb 19 16:10
    SDAChess commented #376
  • Feb 19 16:08
    SDAChess commented #376
  • Feb 19 15:24
    SDAChess opened #376
  • Feb 07 15:40
    borjasotomayor commented #301
  • Feb 06 18:44
    Sombre0mbre opened #375
  • Feb 05 20:49
    xfbs opened #374
  • Feb 04 10:04
    MrAnno edited #301
  • Feb 04 09:59
    MrAnno commented #301
  • Jan 29 20:16
    HugoGDRM commented #223
  • Jan 27 21:01
    abkarcher closed #373
  • Jan 27 21:01
    abkarcher commented #373
Dominik
@kaidowei
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
(i.e. handler functions & predicates for instance)
but in any case, you still need to pass the mock id to mmk_mock_create
(since it needs some metadata on the mock, not just the function pointer itself)
Dominik
@kaidowei
hmm, okay, as I'm not forced to reuse the mock definitions, I'm fine with that
for many handlers, you can save a lot of space...
mmk_expect (m, realloc_mock can't you use m to figure realloc_mock out?
Franklin Mathieu
@Snaipe
no unfortunately, because I still need the definition of struct reallocmock_params
(for the compound literal)
Dominik
@kaidowei
I see. If you change the mmk_mock_define to be 1:1 for a function, you could create a mmk_expect_<mymock> for each declaration and the user would not need to carry the m around
mmk_mock_create ("realloc", NULL, realloc_mock) could be reduced to mmk_mock_create(realloc)
Franklin Mathieu
@Snaipe
bad idea
you still need to define what realloc you're changing
Dominik
@kaidowei
what do you mean with "what realloc"?
Franklin Mathieu
@Snaipe
is it the one used by the current program, or the one used by the library, or the one used by the libc?
Dominik
@kaidowei
put the optional path behind realloc
Franklin Mathieu
@Snaipe
there are as many plt addresses for realloc as there are dynamic modules
this means that you need at least two parameters
so mmk_mock_create("realloc@libc", mock_id)
for instance
Dominik
@kaidowei
yeah, so in summary:
  • I save 1 parameter at _create
  • I do not need to carry mmk_mock m around
  • I have 1 parameter less at mmk_expect
don't think it's so bad :)
Franklin Mathieu
@Snaipe
somethink like that, yeah
there are still some quirks, mostly in the definition part, but it's acceptable
Other API styles should also be explored
I'd like to test out cmocka's style where you implement your stub with macros
Dominik
@kaidowei
okay. I don't like their style very much, because normally the body of a mocking function is always the same and if you need some special syntax, you can still use a custom stub
do you want to use their --wrap approach too or use your stubs?
Franklin Mathieu
@Snaipe
our stubs
but if we implement something like that, it will probably be the same line-wise
Dominik
@kaidowei
yes.
What still is not ideal: we still generate a mock for every function, even if we don't use an external generator
Franklin Mathieu
@Snaipe
something like
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(NULL, ptr == NULL, size == 42);
    mmk_mock_end;
}

we still generate a mock for every function

Explain? I don't really see why that's an issue

Oh, wait, I got it