linux-kernel - RE: [PATCH] [ACPI] utilities/: Compliment va_start() with va

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Nov 2007 16:52:01 -0800
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Richard Knutsson" <ricknu-0@...dent.ltu.se>
Cc:	"Len Brown" <lenb@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-acpi@...r.kernel.org>
Subject: RE: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end().

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@...dent.ltu.se]
>Sent: Monday, November 26, 2007 4:16 PM
>To: Moore, Robert
>Cc: Len Brown; linux-kernel@...r.kernel.org; linux-acpi@...r.kernel.org
>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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/