[ltt-dev] [UST PATCH 1/5] Make app socket directories per-user

Mathieu Desnoyers compudj at krystal.dyndns.org
Tue Mar 29 15:33:12 EDT 2011


* Nils Carlson (nils.carlson at ludd.ltu.se) wrote:
>
> On Mar 29, 2011, at 6:03 PM, Mathieu Desnoyers wrote:
>
>> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
>>> * Nils Carlson (nils.carlson at ericsson.com) wrote:
>> [...]
>>> Please document that the caller must free the char * returned.
>>>
>>>> +char *ustcomm_user_sock_dir(void)
>>>> +{
>>
>> Actually, thinking about it a little more, we should probably even use 
>> a
>> naming convention that tells us we need to free memory returned by the
>> function return value pointer everywhere so that we can audit the  
>> caller
>> code easily for missing "free()".
>>
>> e.g., in this case:
>>
>> char *ustcomm_alloc_user_sock_dir(void)
>>
>> Thoughts ?
>>
>
> Well, I agree that this can be a good principle, especially for structs, 
> but I think
> that for (char *) this is overkill. If something returns a (char *) you 
> expect it
> to allocate memory, unless it explicitly states that it doesn't.

It's mostly for the caller site: when doing a code review, I always make
sure all paths doing *alloc have an associated free(). By hiding this
allocation from the caller site, it makes the reviewer's job much
harder, because we have to dig into the callee to understand what's
happening in the caller. So it's not as much to document the function
prototype (which as you say for "char *", is pretty much
self-explanatory), but rather to document the caller sites.

Thanks,

Mathieu

>
> But documenting is good.
>
> /Nils
>
>
>
>> Thanks,
>>
>> Mathieu
>>
>> -- 
>> Mathieu Desnoyers
>> Operating System Efficiency R&D Consultant
>> EfficiOS Inc.
>> http://www.efficios.com
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com




More information about the lttng-dev mailing list