Ali,
Sorry for the misunderstanding. I'm not soliciting for new members.
If there happens to be anyone on this list who is an IISP member and lives
in the USA
and would be interested in forming a chapter on this side of the Atlantic
then I'd like to
work with them to establish it.
That's
On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote:
| It is, of course, the height of irony that the bug was introduced in
| the very process, and for the very purpose, of attaining FIPS
| compliance!
|
| But also to be expected, because the feature in question is
|
On Tue, 11 Dec 2007, Leichter, Jerry wrote:
You can almost, but not quite, get the desired effect for memory zero-
ization with volatile.
I thought that this was guaranteed to work:
volatile char buf[SIZE];
/* ... do stuff with buf ... */
memset(buf, 0, sizeof(buf));
On Wed, Dec 12, 2007 at 05:27:38PM -0500, Thierry Moreau wrote:
As a consequence of alleged consensus above, my understanding of the C
standard would prevail and (memset)(?,0,?) would refer to an external
linkage function, which would guarantee (to the sterngth of the above
consensus)
How will this be any different from being a member of ISC2 or ISACA?
Why do we need to be a member of yet another organization?
saqib
http://www.quantumcrypto.de/dante/
On Dec 12, 2007 12:21 PM, Alex Alten [EMAIL PROTECTED] wrote:
Would anyone on this list be interested in forming a USA
On 12/12/07, John Denker [EMAIL PROTECTED] wrote:
Several important steps in the process must be carried out in
secret, and if there is any leakage, there is unbounded potential
for vote-buying and voter coercion.
I've done quite a bit of work with this protocol. The protocol assumes
the
James A. Donald [EMAIL PROTECTED] writes:
At every block boundary, keyboard transmits a special signal in the clear
that signifies block boundary. Any time that no key has been pressed for a
while, then when a key is finally pressed, keyboard transmits a bunch of no-
ops sufficient to ensure
I've been through the code. As far as I can see, there's nothing in
expand_builtin_memset_args that treats any value differently, so there can't be
anything special about memset(x, 0, y). Also as far as I can tell, gcc doesn't
optimise out calls to memset, not even thoroughly dead ones: for
On Thu, 13 Dec 2007 21:11, [EMAIL PROTECTED] said:
volatile char buf[SIZE];
/* ... do stuff with buf ... */
memset(buf, 0, sizeof(buf));
This has the little disadvantage that you need to check the attributes
of BUF first and that you can't immediately see what the memset is