[EMAIL PROTECTED] wrote:
>
> >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.
>
That would mean that the ASN1_ITEM couldn't be constant which would add
its own overheads. Ah I see I didn't mention that... well I will now:
each ASN1_ITEM and the related structures they point to such as
ASN1_TEMPLATE are currently completely constant.
> > 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++;}
>
Well in current releases there are many such functions. Indeed almost
every ASN1 element has at least four functions associated with it. The
revised ASN1 code still has them but they could be eliminated at some
point to leave only the single function returning the ASN1_ITEM pointer.
I'm not too sure what purpose "registration" would serve in this system.
> >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.
Well it does reduce runtime overhead but having said that I don't think
the overhead is likely to be much compared to some of the other
operations associated with the processing of each ASN1_ITEM such as
encoding, decoding or dynamic allocation.
Unfortunately removing 'const' from ASN1_ITEM will presumably mean that
they end up being in the data rather than the text segment and each
process needs its own copy of exactly the same data.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
