From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsdyK-000754-Bn for qemu-devel@nongnu.org; Fri, 28 Jun 2013 15:04:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsdyH-0005ao-Nx for qemu-devel@nongnu.org; Fri, 28 Jun 2013 15:04:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsdyH-0005ac-Ee for qemu-devel@nongnu.org; Fri, 28 Jun 2013 15:04:37 -0400 Message-ID: <51CDDEC8.1050005@redhat.com> Date: Fri, 28 Jun 2013 21:06:48 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <51CB9EB9.7030008@hds.com> <51CC1220.6000908@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] Add timestamp to error message List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Seiji Aguchi Cc: "kwolf@redhat.com" , "aliguori@us.ibm.com" , "stefanha@gmail.com" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "armbru@redhat.com" , "dle-develop@lists.sourceforge.net" , Tomoki Sekiyama , "pbonzini@redhat.com" , "lcapitulino@redhat.com" On 06/28/13 20:54, Seiji Aguchi wrote: > >>> diff --git a/include/qemu/time.h b/include/qemu/time.h >>> new file mode 100644 >>> index 0000000..f70739b >>> --- /dev/null >>> +++ b/include/qemu/time.h >>> @@ -0,0 +1,11 @@ >>> +#ifndef TIME_H >>> +#define TIME_H >> >> I wonder if TIME_H is maybe a bit too nondescript and could conflict >> with other guards. >> >> The guards currently used in "include/qemu/*.h" files are inconsistent >> -- some use a QEMU_ prefix, some a __QEMU_ one, and others use none. >> >> Don't respin just because of this, but maybe it's something to consider. > > This should be discussed in other thread... Ah, right, apologies for the ambiguity. I just meant that either QEMU_TIME_H or __QEMU_TIME_H would have a lower chance to clash with another guard than plain TIME_H -- "some" prefix would be nice, but I couldn't point out a specific one, because the current practice varies. I didn't mean to suggest that you should unify the prefixes across all guards! Anyway, even my QEMU_TIME_H / __QEMU_TIME_H suggestion is tangential; feel free to ignore it. Thanks Laszlo