Hi All,
I'm new to OpenSSL and am tring to understand the code. Have a very
basic question. I can't seem to find the functions SHA1_Init(),
SHA1_Update(), SHA1_final() in the source. I only see their prototypes
defined in crypto\sha\sha.h. I'm looking at the latest distribution
0.9.8e
I'd be
On 3/28/07, Darryl Miles [EMAIL PROTECTED] wrote:
Actually 'volatile' doesn't provide a useful fix.
[...]
The problem occurs after the beginning of the function. If the compare is
done on a cached copy in a register. Look at this example:
if (variable!=NULL)
{
free(variable);
Hi,
building apps/ocsp.c fails on Cygwin like this:
gcc [...] -c -o ocsp.o ocsp.c
ocsp.c: In function `query_responder':
ocsp.c:1262: error: storage size of 'tv' isn't known
ocsp.c:1290: warning: implicit declaration of function `select'
ocsp.c:1262: warning: unused variable `tv'
Hi,
the below patches are supposed to help with an annoying DLL problem on
Cygwin. Since Windows doesn't provide a native fork implementation,
Cygwin emulates fork by creating a new process and overwrites the
forkee's memory with data from the forker. This method only works if
the OS doesn't
This is the precise optimization that 'volatile' inhibits.
For single-threaded code, you are right. But we are talking about
multi-threaded code.
'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
If you have multiple threads accessing it, you manage access using a
mutex. If locking is important to the application that it's in.
(Clearing the compression is as important as clearing the library
state. If there's a lock around the library state clearing, a lock
needs to exist around the
A read of a 'volatile uint64_t', btw, is supposed to make sure that it
reads from the original memory locations, not cached copies of it in
register or spread across multiple registers.
Which it doesn't do on any platform I know of. On every platform, 'volatile'
reads through the caches and
A read of a 'volatile uint64_t', btw, is supposed to make sure that it
reads from the original memory locations, not cached copies of it in
register or spread across multiple registers.
No. The computing model in ANSI/ISO C doesn't really go below the level
of source code.
Volatile only
Hi,
building apps/ocsp.c fails on Cygwin like this:
gcc [...] -c -o ocsp.o ocsp.c
ocsp.c: In function `query_responder':
ocsp.c:1262: error: storage size of 'tv' isn't known
ocsp.c:1290: warning: implicit declaration of function `select'
ocsp.c:1262: warning: unused variable `tv'
Hi,
the below patches are supposed to help with an annoying DLL problem on
Cygwin. Since Windows doesn't provide a native fork implementation,
Cygwin emulates fork by creating a new process and overwrites the
forkee's memory with data from the forker. This method only works if
the OS doesn't
Kyle Hamilton wrote:
On 3/28/07, Darryl Miles [EMAIL PROTECTED] wrote:
The problem occurs after the beginning of the function. If the
compare is
done on a cached copy in a register. Look at this example:
if (variable!=NULL)
{
free(variable);
variable=NULL;
}
This could easily be
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
locations like the original memory -- because it may be changed from
outside the
Richard Salz wrote:
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
locations like the original memory -- because it may be changed from
Darryl Mile wrote:
A compiler will not generate a store instruction to put back a
cached_copy into the variable location. Principally because there was
no assignment operation in the original code and because even a
non-optimizing compiler knows it can just dump the cached_copy
I was not commenting on any part of the message that I didn't quote. :)
Kyle's claim about things like cache's and registers is wrong, not even
sort-of right. The standard talks about only in terms of sequence points,
and volatile limits what can be done in terms of sequence points. So
Applied with a twist (On VMS, time.h defines select(), according to
docs. Why? Beats me) and committed.
Thanks!
Cheers,
Richard
In message [EMAIL PROTECTED] on Thu, 29 Mar 2007 11:33:04 +0200, Corinna
Vinschen [EMAIL PROTECTED] said:
vinschen Hi,
vinschen
vinschen building apps/ocsp.c
Richard Salz wrote:
Kyle's claim about things like cache's and registers is wrong, not even
sort-of right. The standard talks about only in terms of
sequence points,
and volatile limits what can be done in terms of sequence points. So
extern volatile char* p;
int i, j;
Suppose another thread does this:
*p=99;
*p=98;
Out of scope -- the C standard does not define ANY semantics for multiple
threads of execution.
The standard is discussed in terms of an abstract machine and the
machine
the code is running on may bear only as much resemblance to the
18 matches
Mail list logo
