Re: [Qemu-devel] [PATCH] HACKING: Clarify the paragraph about typedefs

[Greg Kurz <groug@kaod.org>]

On Fri, 11 Jan 2019 13:12:23 +0100
Cédric Le Goater <clg@kaod.org> wrote:

> On 1/11/19 11:38 AM, Paolo Bonzini wrote:
> > On 11/01/19 09:42, Thomas Huth wrote:  
> >>  2.3. Typedefs
> >> -Typedefs are used to eliminate the redundant 'struct' keyword.
> >> +Typedefs can be used to eliminate the redundant 'struct' keyword. This is
> >> +especially helpful for common types that are used all over the place. Since
> >> +certain C compilers choke on duplicated typedefs, you should avoid them and
> >> +declare a typedef only in one header file. For common types, you can use
> >> +"include/qemu/typedefs.h" for example. Note that it is also perfectly fine to
> >> +use forward struct definitions without typedefs for references in headers
> >> +to avoid the problem with duplicated typedefs.
> >>    
> > 
> > I agree 100% with the wording after "Since".  However, I think the first
> > part should be made stronger, not weaker.
> > 
> > Typedefs are use to eliminate the redundant 'struct' keyword, since type
> > names have a different style than other identifiers ("CamelCase" versus
> > "snake_case").  Each struct should have a CamelCase name and a
> > corresponding typedef.
> > 
> > Since certain C compilers choke on duplicated typedefs, you should avoid
> > them and declare a typedef only in one header file.  For common types,
> > you can use "include/qemu/typedefs.h" for example.  However, as a metter
> > of convenience it is also perfectly fine to use forward struct
> > definitions instead of typedefs in headers and function prototypes; this
> > avoids problems with duplicated typedefs and reduces the need to include
> > headers from other headers.  
> 
> I suppose this is difficult to check with checkpatch ? It's easy to
> cross the border as I have proven many times. 

With Thomas's series merged, a simple build with clang will catch the
duplicated typedefs. Not sure it is worth the pain to teach checkpatch.

>  
> > And, I would move it to CODING_STYLE since we are at it. :)  
> 
> yes.
> 
> C.
>