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

[Michal Privoznik]

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.

Michal