> > time_t TSPX_GENERALIZEDTIME_print(BIO *bp, ASN1_GENERALIZEDTIME *tm,int gmt) {
> ...
> > if (strncmp(tm->data,strtime,15) < 0)
> > test -= (time_t)(1 << i) ;
>
> This is curious code. It is trying to treat the TIME datatype as
> opaque, but then it looks directly at the data field. :) Why not just
> look at the data field, understand the decoding, and crack it open
> directly? I.e., look at ASN1_GENERALIZEDTIME_set() and
> ASN1_UTCTIME_set().
The code isn't quite correct if tm->data has subseconds, or time zones,
this should be normalized before making the tests.
But why should one bother to understand the correct details of strftime
to calculate the inverse function. Just making a binary search through
the possible values avoids some errors.
>
> it would be nicer if Dr. Henson wrote ASN1_TIME_to_time_t, tho. :)
> But see below.
>
> > long ASN1_INTEGER_get(ASN1_INTEGER *a)
>
> The problem is that this fails if the number can't fit into a long. (For
> example, a CA which puts a 128bit UUID/GUID as the certificate serial
> number.) And there's no clean way to tell (a bit ugly, indeed:). The
> ASN_TIME_get function could have the same problem, since a four-digit
> year could easily exceed the common 32bit implementation of time_t ...
There is always this conflict, these routines are too be
used when the range of the integer is small, for things like serialnumbers,
one would just use the octet representation anyway.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
