Update on this:

the change you propose seems to work fine except that the problem seems to
be with successive encoding/decoding operations. That is to say, I can
encode/decode *once*, but when I do another successive encode/decode in same
program, I get the original error back
Is there a macro for "resetting the template"?

Why didn't I see this problem in NSS3.1?

-- P

"Patrick" <[EMAIL PROTECTED]> wrote in message
3c917f85$[EMAIL PROTECTED]">news:3c917f85$[EMAIL PROTECTED]...
> Thanks. So you mean, do this:
>
> SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)
>
> static SEC_ASN1Template template[] = {
>   { SEC_ASN1_SEQUENCE, 0, NULL, sizeof (SDRResult) },
>   { SEC_ASN1_OCTET_STRING, offsetof(SDRResult, keyid) },
>   { SEC_ASN1_INLINE | SEC_ASN1_XTRN, offsetof(SDRResult, alg),
> SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) },
>     //{ SEC_ASN1_INLINE, offsetof(SDRResult, alg),
> NSS_Get_SECOID_AlgorithmIDTemplate },
>   { SEC_ASN1_OCTET_STRING, offsetof(SDRResult, data) },
>   { 0 }
> };
>
> Can I safely use this template in successive SEC_ASN1DecodeItem and
> SEC_ASN1EncodeItem calls?
> I seem to be getting the same error even after the change...
>
> -- P
>
> "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > I should correct something I wrote in that last reply.  I wrote:
> > >
> > > Patrick wrote:
> >
> > > > I had to use NSS_Get_SECOID_AlgorithmIDTemplate instead of
> > > > SECOID_AlgorithmIDTemplate in order to get the code to compile:
> > > >
> > > > static SEC_ASN1Template template[] = {
> > > > { SEC_ASN1_SEQUENCE, 0, NULL, sizeof (SDRResult) },
> > > > { SEC_ASN1_OCTET_STRING, offsetof(SDRResult, keyid) },
> > > > { SEC_ASN1_INLINE, offsetof(SDRResult, alg),
> > > > NSS_Get_SECOID_AlgorithmIDTemplate },
> > > > { SEC_ASN1_OCTET_STRING, offsetof(SDRResult, data) },
> > > > { 0 }
> > > > };
> >
> > > > When my app runs, Windows throws an "Exception Breakpoint error:
> breakpoint
> > > > has been reached (0x800000003)" error message...I attached the stack
> trace
> > > > from MSVC++.
> > >
> > > > Is there a bug here? What's the Breakpoint error all about?
> > >
> > > You changed the third part of the triplet to be correct for Windows,
but
> > > you didn't change the first part to go with it.
> >
> > That's not quite right.  I should have written:
> >
> > You changed the address of the template (which is a data item in another
> > DLL) to the address of a function in that other DLL.  Changing the
address
> > of the template into the address of the function was not the right
> > solution for windows.
> >
> > Windows can link the address of the function (unlike the address of a
data
> > item) in another DLL, so the build succeeded.  But at run time the code
> > that interpreted the template attempted to interpret the instructions of
> > the function as if they were a template, and ... blammo.
> >
> > The correct solution for windows, which is done by those macros I
> > described in the previous message, has two parts:
> > 1. Change the address of the external template to the address of a
pointer
> > to a function (in that other DLL) that returns the address of the
template
> > (also in that other DLL), and
> > 2. Set a flag that tells the template interpreter to call the function
> > through that pointer, rather than using the address of the pointer as a
> > template address.
> >
> > On windows, the macro SEC_ASN1_MKSUB creates the pointer to the
function;
> > the macro SEC_ASN1_SUB expands to the address of that pointer, and
> > the macro SEC_ASN1_XTRN sets the flag to tell the template interpreter
> > how to use that address.  On Unix, these macros are more-or-less no-ops.
> >
> > --
> > Nelson Bolyard               Netscape
> > Disclaimer:                  I speak for myself, not for Netscape
>
>



Reply via email to