Re: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end().

[Richard Knutsson]

Moore, Robert wrote:
> Yes, it's official ANSI C, so I agree with the portability. I'm probably
> asking more about the history of the thing.
>
>   
"the history of the thing"? Sorry, you lost me there. I know there were 
a pre-ANSI
version of va_start() & co., but they seemed quite messy. When it comes 
to va_end()
and maintainers, they often seem positive to this. I guess the 
occasional lack off
va_end() is usually an oversight.
>   
> > -----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-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/