A minor nitpick, but...
On Fri, Apr 23, 2010 at 11:35:05AM +0100, Davide Brini wrote:
> On Friday 23 Apr 2010 11:13:21 David Sommerseth wrote:
> > On 22/04/10 23:37, Davide Brini wrote:
> > > --- openvpn-2.1.1/ssl.c 2010-02-28 22:17:45.000000000 +0000
> > > +++ openvpn-2.1.1-a/ssl.c 2010-04-22 22:33:40.000000000 +0100
> > > @@ -788,9 +788,28 @@ verify_callback (int preverify_ok, X509_
> > >
> > > /* export serial number as environmental variable */
> > > {
> > > - const int serial = (int) ASN1_INTEGER_get (X509_get_serialNumber
> > > (ctx->current_cert)); + BIO *bio = NULL;
> > > + char serial[1024] = {0};
[...]
> > The initialisation is also rather bogus, as it will only put \0 in the
> > first byte, not the complete string. It's better to instead use
> > CLEAR (serial) afterwards (which is a wrapper for memset()).
>
> Ok, will do that. But anyway, since it's meant to be a string, I thought that
> initializing it to '\0' would mean "empty string".
The initialization will, in fact, set all bytes of "serial" to zero.
Quoting the C standard (well, C89 draft is the closest I have):
"If there are fewer initializers in a list than there are members of
an aggregate, the remainder of the aggregate shall be initialized
implicitly the same as objects that have static storage duration."
Which means filling with zeroes:
"If an object that has static storage duration is not initialized
explicitly, it is initialized implicitly as if every member that has
arithmetic type were assigned 0 and [--]"
I.e. you cannot "partially" initialize an object: the array elements not
mentioned in the initializer are implicitly initialized to zero. You
only get indeterminate values by omitting the initializer completely.
I guess it's concievable some compiler could get this wrong, though...
--
Heikki Kallasjoki
heikki.kallasj...@iki.fi
