On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote:
> >
> > Log:
> > New functions CRYPTO_set_idptr_callback(),
> > CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type
> > thread ID, since the 'unsigned long' type of the existing thread ID
> > does not always work well.
>
> To clarify this, if CRYPTO_get_idptr_callback() is used, is it
> unnecessary to also call CRYPTO_set_id_callback?
>
> Does C9x actually guarantee that you can take the address of errno?
>From C99, section 7.5:
[#1] The header <errno.h> defines several macros, all
relating to the reporting of error conditions.
[#2] The macros are
EDOM
EILSEQ
ERANGE
which expand to integer constant expressions with type int,
distinct positive values, and which are suitable for use in
#if preprocessing directives; and
errno
which expands to a modifiable lvalue170) that has type int,
the value of which is set to a positive error number by
several library functions. It is unspecified whether errno
is a macro or an identifier declared with external linkage.
If a macro definition is suppressed in order to access an
actual object, or a program defines an identifier with the
name errno, the behavior is undefined.
[...]
170The macro errno need not be the identifier of an object.
It might expand to a modifiable lvalue resulting from a
function call (for example, *errno()).
And:
6.5.3.2 Address and indirection operators
Constraints
[#1] The operand of the unary & operator shall be either a
function designator, the result of a [] or unary * operator,
or an lvalue that designates an object that is not a bit-
field and is not declared with the register storage-class
specifier.
I believe you can take the address of errno.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
