On Thu, 2013-02-21 at 05:15 -0500, Jeffrey Walton wrote:
> You enabled it with -Wextra, then you turned it off with
> -Wno-missing-field-initializers. Its not latched - the last option
> wins.
Good catch! I forgot to remove that while doing some rapid prototyping.
> In addition, GCC's analysis m
On Thu, Feb 21, 2013 at 1:37 AM, Nick wrote:
> On Mon, 2013-02-18 at 08:56 -0500, Jeffrey Walton wrote:
>> > g++-4.7.2 -g -Wall -Wextra -Weffc++ -Wno-missing-field-initializers
>> > -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wold-style-cast
>> > -Woverloaded-virtual -Werror -std=c++11
>> -W
On Mon, 2013-02-18 at 08:56 -0500, Jeffrey Walton wrote:
> > g++-4.7.2 -g -Wall -Wextra -Weffc++ -Wno-missing-field-initializers
> > -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wold-style-cast
> > -Woverloaded-virtual -Werror -std=c++11
> -Wno-missing-field-initializers :)
Firstly, -Wno-miss
On Mon, Feb 18, 2013 at 8:31 AM, Nick wrote:
> On Mon, 2013-02-18 at 08:12 -0500, Jeffrey Walton wrote:
>> It looks like the GCC tool chain has let you down: "C/C++ Option to
>> Initialize Variables?",
>> http://gcc.gnu.org/ml/gcc/2013-02/msg00207.html.
>>
>> Visual Studio has a similar feature fo
On Mon, 2013-02-18 at 14:18 +0100, Dr. Stephen Henson wrote:
> > Can you confirm the same logic applies to d2i_X509_fp?
> >
>
> Yes, it applies to any function of the form d2i__fp.
>
I'll make the appropriate changes elsewhere then.
Thank you very much for your prompt & helpful responses.
Ni
On Mon, 2013-02-18 at 08:12 -0500, Jeffrey Walton wrote:
> It looks like the GCC tool chain has let you down: "C/C++ Option to
> Initialize Variables?",
> http://gcc.gnu.org/ml/gcc/2013-02/msg00207.html.
>
> Visual Studio has a similar feature for debug builds, and I don't ever
> recall being burn
On Mon, Feb 18, 2013, Nick wrote:
> On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
> > Here's what's happening in detail. If you pass a non-NULL pointer for
> > the
> > second parameter it will attempt to reuse the structure.
> >
> > In the case of the RSA structure the outer (RSA *
On Mon, Feb 18, 2013 at 7:58 AM, Nick wrote:
> On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
>> Here's what's happening in detail. If you pass a non-NULL pointer for
>> the
>> second parameter it will attempt to reuse the structure.
>>
>> In the case of the RSA structure the outer (
On Mon, 2013-02-18 at 13:22 +0100, Dr. Stephen Henson wrote:
> Here's what's happening in detail. If you pass a non-NULL pointer for
> the
> second parameter it will attempt to reuse the structure.
>
> In the case of the RSA structure the outer (RSA *) is allocated via
> OPENSSL_malloc and so are
On Mon, Feb 18, 2013, Nick wrote:
> On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
> > That's because it is attempting to free up parts of a pointer that
> > haven't
> > been allocated with OPENSSL_malloc. See:
> >
> > http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
> >
>
On Mon, 2013-02-18 at 04:00 -0500, Jeffrey Walton wrote:
> The signature is X509 *d2i_X509_fp(FILE *fp, X509 **x);
>
Please re-read my previous response. I'm not having a problem w/ the
code involving x509. I included it in my last response to point out
that while it works fine, calling d2i_RSA
On Mon, Feb 18, 2013 at 3:04 AM, Nick wrote:
> On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
>> That's because it is attempting to free up parts of a pointer that
>> haven't
>> been allocated with OPENSSL_malloc. See:
>>
>> http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
>
On Mon, 2013-02-18 at 00:37 +0100, Dr. Stephen Henson wrote:
> That's because it is attempting to free up parts of a pointer that
> haven't
> been allocated with OPENSSL_malloc. See:
>
> http://www.openssl.org/docs/crypto/d2i_X509.html#WARNINGS
>
Changing the code to allocate the struct via OPEN
On Sun, Feb 17, 2013, Nick wrote:
> Calling d2i_RSAPrivateKey_fp with the address of a non-NULL 2nd param
> yields a seg fault for me. It seems to work if I pass the address of a
> NULL ptr instead (commented out in the repro code below).
>
> I'm calling it in the same manner that I call d2i_X50
Calling d2i_RSAPrivateKey_fp with the address of a non-NULL 2nd param
yields a seg fault for me. It seems to work if I pass the address of a
NULL ptr instead (commented out in the repro code below).
I'm calling it in the same manner that I call d2i_X509_fp which also
works.
Environment:
OpenSSL
15 matches
Mail list logo