RFC: do we want/need the "Ptr" typedefs for internal code ?

[Michal Privoznik]

On 3/10/21 4:36 PM, Michal Privoznik wrote:
> On 3/9/21 6:44 PM, Daniel P. Berrangé wrote:
>> One of the conventions we have had since the early days of libvirt is
>> that every struct typedef, has a corresponding "Ptr" typedef too.
>>
>> For example
>>
>>      typedef struct _virDomainDef virDomainDef;
>>      typedef virDomainDef *virDomainDefPtr;
>>
>> Periodically someone has questioned what the purpose of these Ptr
>> typedefs is, and we've not had an compelling answer, other than
>> that's what we've always done.
>>
> 
> One possible upside is that it allows for less scary function headers, 
> for instance:
> 
> virDomainChrGetDomainPtrsInternal(virDomainDefPtr vmdef,
>                                    virDomainChrDeviceType type,
>                                    virDomainChrDefPtr ***arrPtr,
>                                    size_t **cntPtr);
> 
> Three levels of dereference don't look as bad as four.
> But yeah, I agree we should drop them. I wonder if cocci can help here. 
> Or even plain in-place sed, except we'd have to be careful with 
> statements like:
> 
>    virSomethingPtr a, b;
> 
> where both @a and @b are pointers, and plain substitution would break it:
> 
>    virSomething *a, b;
> 
> (here only @a is poitner, ofc).
> 
> But since we have Peter nagging about this kind of variable declaration, 
> it's not something one couldn't fix by hand. And in fact, whilst we're 
> at it we could declare each variable at its own line.

Okay, another problem: how does this g_auto() and similar work? I mean, 
now we have:

G_DEFINE_AUTO_CLEANUP_FREE_FUNC(virSysinfoDefPtr, virSysinfoDefFree, NULL);

and it works fine. But obviously either of:

G_DEFINE_AUTO_CLEANUP_FREE_FUNC(virSysinfoDef *, ...);
G_DEFINE_AUTO_CLEANUP_FREE_FUNC(virSysinfoDef, ...);

is plain wrong. Maybe we can switch to g_autoptr() instead.

Michal