>There are a couple of problems with that as it stands. One minor issue
>is that the current code declares ASN1_ITEM as extern e.g.
>
>extern ASN1_ITEM ASN1_OCTET_STRING_it;
>
>and the macros turn it into &ASN1_OCTET_STRING_it. Easy enough to change
>though.
Right, that should be a (perhaps tedious) but simple change.
>The main problem is that the various addresses need to be resolved at
>compile time. You'll have a structure where one element is initialised
>to "ku_item" in that example.
Do they really? You could use lazy evaluation, and just store the NID
and on first use, go fill in the pointers.
> However you then get
>the additional problem of how you get any new ASN1_ITEM structures
>declared by an external program or library into this model and in such
>as way that other programs or libraries can initialise them at compile
>time.
Similar lazy evaluation. Have a flag byte in your ASN1_ITEM structure
that declares whether or not this item is registered.
>const ASN1_ITEM *ASN1_OCTET_STRING_it(void) {
> static const ASN1_ITEM ASN1_OCTET_STRING_internal = {/* Some definition
>*/};
/* see below */
> return &ASN1_OCTET_STRING_internal;
>}
At the cost of many such functions, that works. It also gives you a
mechanism to force registration into your runtime table, replacing the
"see below" comment above with
static int beenhere = 0;
if (!beenhere) { ASN1_register(ASN1_OCTET_STRING_internal); beenhere++;}
>and then you place a function pointer ASN1_OCTET_STRING_it in the
>structures that need to access it and it is converted at runtime. You'd
>then have various macros that select whichever method was appropriate on
>the particular platform and act appropriately.
I think doing the lazy eval gives you a better trade-off, since the pointers
are eval'd once, not every time they're used.
/r$
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
