2007-06-12 23:33:18

by Dave Jones

[permalink] [raw]
Subject: Fix empty macros in acpi.

ACPI has a ton of macros which make a bunch of empty if's
when configured in non-debug mode.

Signed-off-by: Dave Jones <[email protected]>

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 4334c20..5955cfd 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -16,7 +16,7 @@
#if ACPI_GLUE_DEBUG
#define DBG(x...) printk(PREFIX x)
#else
-#define DBG(x...)
+#define DBG(x...) do { } while(0)
#endif
static LIST_HEAD(bus_type_list);
static DECLARE_RWSEM(bus_type_sem);
diff --git a/include/acpi/acmacros.h b/include/acpi/acmacros.h
index 8948a64..e64a748 100644
--- a/include/acpi/acmacros.h
+++ b/include/acpi/acmacros.h
@@ -599,26 +599,26 @@
#define ACPI_DEBUG_EXEC(a)
#define ACPI_NORMAL_EXEC(a) a;

-#define ACPI_DEBUG_DEFINE(a)
-#define ACPI_DEBUG_ONLY_MEMBERS(a)
-#define ACPI_FUNCTION_NAME(a)
-#define ACPI_FUNCTION_TRACE(a)
-#define ACPI_FUNCTION_TRACE_PTR(a,b)
-#define ACPI_FUNCTION_TRACE_U32(a,b)
-#define ACPI_FUNCTION_TRACE_STR(a,b)
-#define ACPI_FUNCTION_EXIT
-#define ACPI_FUNCTION_STATUS_EXIT(s)
-#define ACPI_FUNCTION_VALUE_EXIT(s)
-#define ACPI_FUNCTION_ENTRY()
-#define ACPI_DUMP_STACK_ENTRY(a)
-#define ACPI_DUMP_OPERANDS(a,b,c,d,e)
-#define ACPI_DUMP_ENTRY(a,b)
-#define ACPI_DUMP_TABLES(a,b)
-#define ACPI_DUMP_PATHNAME(a,b,c,d)
-#define ACPI_DUMP_RESOURCE_LIST(a)
-#define ACPI_DUMP_BUFFER(a,b)
-#define ACPI_DEBUG_PRINT(pl)
-#define ACPI_DEBUG_PRINT_RAW(pl)
+#define ACPI_DEBUG_DEFINE(a) do { } while(0)
+#define ACPI_DEBUG_ONLY_MEMBERS(a) do { } while(0)
+#define ACPI_FUNCTION_NAME(a) do { } while(0)
+#define ACPI_FUNCTION_TRACE(a) do { } while(0)
+#define ACPI_FUNCTION_TRACE_PTR(a,b) do { } while(0)
+#define ACPI_FUNCTION_TRACE_U32(a,b) do { } while(0)
+#define ACPI_FUNCTION_TRACE_STR(a,b) do { } while(0)
+#define ACPI_FUNCTION_EXIT do { } while(0)
+#define ACPI_FUNCTION_STATUS_EXIT(s) do { } while(0)
+#define ACPI_FUNCTION_VALUE_EXIT(s) do { } while(0)
+#define ACPI_FUNCTION_ENTRY() do { } while(0)
+#define ACPI_DUMP_STACK_ENTRY(a) do { } while(0)
+#define ACPI_DUMP_OPERANDS(a,b,c,d,e) do { } while(0)
+#define ACPI_DUMP_ENTRY(a,b) do { } while(0)
+#define ACPI_DUMP_TABLES(a,b) do { } while(0)
+#define ACPI_DUMP_PATHNAME(a,b,c,d) do { } while(0)
+#define ACPI_DUMP_RESOURCE_LIST(a) do { } while(0)
+#define ACPI_DUMP_BUFFER(a,b) do { } while(0)
+#define ACPI_DEBUG_PRINT(pl) do { } while(0)
+#define ACPI_DEBUG_PRINT_RAW(pl) do { } while(0)

#define return_VOID return
#define return_ACPI_STATUS(s) return(s)



--
http://www.codemonkey.org.uk


2007-06-13 00:00:39

by Al Viro

[permalink] [raw]
Subject: Re: Fix empty macros in acpi.

On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> +#define DBG(x...) do { } while(0)

Eh... Please, stop it - if you want a function-call-like no-op returning void,
use ((void)0). At least that way one can say DBG(....),foo(), etc.

2007-06-13 00:21:52

by Dave Jones

[permalink] [raw]
Subject: Re: Fix empty macros in acpi.

On Wed, Jun 13, 2007 at 01:00:29AM +0100, Al Viro wrote:
> On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> > +#define DBG(x...) do { } while(0)
>
> Eh... Please, stop it - if you want a function-call-like no-op returning void,
> use ((void)0). At least that way one can say DBG(....),foo(), etc.

They both end up compiled to nothing anyway, so I'm not bothered
either way.. I'm not sure I follow why the syntax of that last part
is a good thing. It looks like something we'd want to avoid rather
than promote?

Dave

--
http://www.codemonkey.org.uk

2007-06-13 00:26:39

by Al Viro

[permalink] [raw]
Subject: Re: Fix empty macros in acpi.

On Tue, Jun 12, 2007 at 08:21:15PM -0400, Dave Jones wrote:
> On Wed, Jun 13, 2007 at 01:00:29AM +0100, Al Viro wrote:
> > On Tue, Jun 12, 2007 at 07:33:09PM -0400, Dave Jones wrote:
> > > +#define DBG(x...) do { } while(0)
> >
> > Eh... Please, stop it - if you want a function-call-like no-op returning void,
> > use ((void)0). At least that way one can say DBG(....),foo(), etc.
>
> They both end up compiled to nothing anyway, so I'm not bothered
> either way.. I'm not sure I follow why the syntax of that last part
> is a good thing. It looks like something we'd want to avoid rather
> than promote?

If on one side of ifdef it's a void-valued expression, so it should be
on another; the reason is that we don't get surprise differences between
the builds...

IOW, if it doesn't build in some context, it should consistently fail to
build in that context.