qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] qemu-error: introduce error_report_once


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH RFC] qemu-error: introduce error_report_once
Date: Thu, 17 May 2018 10:51:10 +0800
User-agent: Mutt/1.9.3 (2018-01-21)

On Wed, May 16, 2018 at 09:02:42AM -0500, Eric Blake wrote:
> On 05/15/2018 10:07 PM, Peter Xu wrote:
> 
> > > > +        static bool __print_once;               \
> > > 
> > > Double-underscore names are reserved for the compiler's use, not ours.
> > > Better would be naming this:
> > > 
> > > static bool print_once_;
> > > 
> > > with a trailing underscore, or at most a single leading underscore.
> > > 
> > > > +        bool __ret_print_once = !__print_once;  \
> > > 
> > > Same comment for this variable.
> > 
> > Sure!
> > 
> > (I am wondering why Linux is always using that way to name lots of
> >   variables, and I'm surprised that I got 385350 after I run this under
> >   the Linux repo: 'git grep "__[a-z][a-z]" | wc -l', even considering
> >   some false positives)
> 
> git grep "\b_[_A-Z]" might be a more precise grep for use of reserved
> identifiers.  The Linux kernel can get away with some uses that qemu does
> not, because it is a monolithic low-level project that is closely tied to
> rather specific compiler behaviors and does not have to port to other
> systems; rather than a user-space application that aims to be portable to
> multiple operating systems, compilers, and libc implementations.  Also,
> grepping for leading double-underscore will have hits even in qemu, where we
> ARE taking advantage of a compiler feature (an obvious example: anywhere we
> #define a macro wrapper around an __attribute__ tag - __attribute__ belongs
> to the namespace reserved for the compiler, so it makes sense that turning
> on that compiler feature requires using the compiler's namespace).  Or put
> another way, grepping for the use of reserved identifiers is easy, but
> grepping for where we are inappropriately declaring something that may
> collide (rather than using something that already exists) is a bit harder.

Ah yes, I suppose it'll at least need a whitelist of existing symbols
that are used in compiler's namespace (like, __attribute__) to make
the number more accurate, which does not really suite for a oneliner
any more.

Good to know the reason finally.  Thanks Eric!

-- 
Peter Xu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]