Yes, it's official ANSI C, so I agree with the portability. I'm probably asking more about the history of the thing. >-----Original Message----- >From: Richard Knutsson [mailto:ricknu-0@xxxxxxxxxxxxxx] >Sent: Monday, November 26, 2007 4:16 PM >To: Moore, Robert >Cc: Len Brown; linux-kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx >Subject: Re: [PATCH] [ACPI] utilities/: Compliment va_start() with >va_end(). > >Moore, Robert wrote: >> 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. >> >> >First off, I think it is a good idea to follow the documentation, which >stated: >"va_end >Each invocation of va_start must be matched by a corresponding >invocation of va_end in the same function." > >Then if it is not really needed, does it take up extra cycles? >"In practice, with most C compilers, calling |va_end| does nothing >and you do not really need to call it. This is always true in the GNU C >compiler."[1] > >Portability: >"But you might as well call |va_end| just in case your >program is someday compiled with a peculiar compiler."[2] >This argument is not as likely thou, but who knows? (Since I guess Intel's >compiler is included in the 'most C compilers') > >> >> We don't set all local pointers to NULL at function exit, what is the >> point of doing it here? >> >I think it is a good thing if the code follows the documentation, both >for the person who tries >to understand the code (to see when the 'args' is no longer needed and >not getting confused >by the absent of va_end(), after all, IMHO we should write the code how >we want things to >work and let the compiler do the optimizations (it usually does a better >job at it then we do)) >and to automated searches (that is how I found this one). >> I suppose some implementation could allocate memory at va_start, but in >> practice, does this happen? >> >Not sure what you mean. >> Bob >> >> >cu >Richard Knutsson > >[1] >http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_28.ht ml >[2] The rest of [1]'s line. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
