Messages in this thread | | | Subject | RE: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end(). | Date | Mon, 26 Nov 2007 14:14:47 -0800 | From | "Moore, Robert" <> |
| |
This is an interesting one to me.
From various documentation:
After all arguments have been retrieved, va_end resets the pointer to NULL.
va_end Each invocation of va_start must be matched by a corresponding invocation of va_end in the same function. After the call va_end(ap) the variable ap is undefined. Multiple transversals of the list, each bracketed by va_start and va_end are possible. va_end may be a macro or a function.
Now, I'm all for defensive programming, but I don't really see the point of va_end when the list will be only traversed once.
We don't set all local pointers to NULL at function exit, what is the point of doing it here?
I suppose some implementation could allocate memory at va_start, but in practice, does this happen?
Bob
>-----Original Message----- >From: Len Brown [mailto:lenb@kernel.org] >Sent: Saturday, November 24, 2007 11:06 PM >To: Moore, Robert >Subject: Fwd: [PATCH] [ACPI] utilities/: Compliment va_start() with >va_end(). > > > >---------- Forwarded Message ---------- > >Subject: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end(). >Date: Saturday 24 November 2007 15:43 >From: Richard Knutsson <ricknu-0@student.ltu.se> >To: len.brown@intel.com >Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Richard >Knutsson <ricknu-0@student.ltu.se> > >Compliment va_start() with va_end(). > >Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se> >--- >Compile-tested on i386 with allyesconfig & allmodconfig. > > utdebug.c | 2 ++ > utmisc.c | 4 ++++ > 2 files changed, 6 insertions(+) > > >diff --git a/drivers/acpi/utilities/utdebug.c >b/drivers/acpi/utilities/utdebug.c >index c7e128e..f45e3d5 100644 >--- a/drivers/acpi/utilities/utdebug.c >+++ b/drivers/acpi/utilities/utdebug.c >@@ -203,6 +203,7 @@ acpi_ut_debug_print(u32 requested_debug_level, > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > } > > ACPI_EXPORT_SYMBOL(acpi_ut_debug_print) >@@ -240,6 +241,7 @@ acpi_ut_debug_print_raw(u32 requested_debug_level, > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > } > > ACPI_EXPORT_SYMBOL(acpi_ut_debug_print_raw) >diff --git a/drivers/acpi/utilities/utmisc.c >b/drivers/acpi/utilities/utmisc.c >index 2d19f71..ca4904c 100644 >--- a/drivers/acpi/utilities/utmisc.c >+++ b/drivers/acpi/utilities/utmisc.c >@@ -1032,6 +1032,7 @@ acpi_ut_error(char *module_name, u32 line_number, >char *format, ...) > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > acpi_os_printf(" [%X]\n", ACPI_CA_VERSION); > } > >@@ -1046,6 +1047,7 @@ acpi_ut_exception(char *module_name, > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > acpi_os_printf(" [%X]\n", ACPI_CA_VERSION); > } > >@@ -1060,6 +1062,7 @@ acpi_ut_warning(char *module_name, u32 line_number, >char *format, ...) > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > acpi_os_printf(" [%X]\n", ACPI_CA_VERSION); > } > >@@ -1076,5 +1079,6 @@ acpi_ut_info(char *module_name, u32 line_number, char >*format, ...) > > va_start(args, format); > acpi_os_vprintf(format, args); >+ va_end(args); > acpi_os_printf("\n"); > } >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > >------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |