Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 20 09:09
    MrAnno commented #380
  • Jul 16 13:45
    RaniAgus edited #380
  • Jul 16 13:44
    RaniAgus edited #380
  • Jun 22 14:23
    samwhitlock commented #281
  • 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
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
(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