Hello Johannes,
W dniu 30.08.2016 o 09:29, Johannes Schindelin pisze:
> On Mon, 29 Aug 2016, Jakub Narębski wrote:
>> W dniu 29.08.2016 o 10:04, Johannes Schindelin pisze:
>>> +void *sequencer_entrust(struct replay_opts *opts, void *set_me_free_after_use)
>>> +{
>>> + ALLOC_GROW(opts->owned, opts->owned_nr + 1, opts->owned_alloc);
>>> + opts->owned[opts->owned_nr++] = set_me_free_after_use;
>>> +
>>> + return set_me_free_after_use;
>>
>> I was wondering what this 'set_me_free_after_use' parameter is about;
>> wouldn't it be more readable if this parameter was called 'owned_data'
>> or 'owned_ptr'?
>
> If I read "owned_ptr" as a function's parameter, I would assume that the
> associated memory is owned by the caller. So I would be puzzled reading
> that name.
Right. Well, it is difficult to come up with a good name for this
parameter that would make sense both in a declaration as an information
for a caller, and in the function itself as information about what it
holds.
In my personal opinion 'set_me_free_after_use' is not the best name,
but I unfortunately do not have a better proposal. Maybe 'entrust_ptr',
or 'entrusted_data' / 'entrusted_ptr' / 'entrusted'?
There are two hard things in computer science: cache invalidation,
*naming things*, and off-by-one errors ;-)
P.S. It would be nice to have generic mechanism for taking custody
of data to help libification, either at this or at lower level (on
the level of xstrdup, etc.), but that can safely wait. It even should
wait, so that we can see that this approach is a good one, before
trying to generalize it. That should be not a blocker for this series,
IMVHO.
Best,
--
Jakub Narębski