[openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example

Hi, running the following example from the openssl wiki site under valgrind gives many memory-leaks in the underlying library functions: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption $ gcc -Wall -O2 test_encdec.c -lcrypto $ valgrind --tool=memcheck --leak-check=full

Re: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example

U.Mutlu wrote on 11/23/2015 06:32 AM: Hi, running the following example from the openssl wiki site under valgrind gives many memory-leaks in the underlying library functions: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption $ gcc -Wall -O2 test_encdec.c -lcrypto Typo

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

Le 22/11/15 17:26, Andy Polyakov via RT a écrit : > > If you want distinguish Solaris, yes. But if you want to distinguish > specifically SunOS 4, 'sun' is guaranteed to do the job. Because > compiler that targets SunOS 4 *has to* have it. Either way, we seem to > agree that *replacing* sun with

[openssl-dev] [openssl.org #4153] [PATCH] Fix grammar errors in s_client.c

This patch fixes small grammar errors in s_client.c. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration

[openssl-dev] [openssl.org #4154] [PATCH] BIO mem read optimization

2 BIO_s_mem issues solved: - BIO mem read without reallocation - reading by parts becomes faster; - flag added to rewind read write BIO mem on reset. OpenSSL self-test report: OpenSSL version: 1.1.0-dev Last change: State machine rewrite. The state machine code has been ... Options:

Re: [openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer

We have another internal cleanup in-progress that will fix this in a different way. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> In other words I argue in favour of reverting suggested change in >> 1.0.1/2. Because I can't find evidence that __sun is defined on said >> platform. >> >> >> >> > FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif I

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

> FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif By the way, was it *actually* tested on SunOS 4? And if so, when and with which compiler? Is it possible that it simply was harmonized at some point with "we have

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

Le 22/11/15 15:42, Andy Polyakov via RT a écrit : >> FWIW, the generally accepted and documented platform tests include: >>> #ifdef __sun >>> /* this is SunOS */ >>> #endif > > By the way, was it *actually* tested on SunOS 4? And if so, when and > with which compiler? Is it possible that it

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

Le 22/11/15 16:29, Richard PALO a écrit : > Le 22/11/15 15:42, Andy Polyakov via RT a écrit : >>> FWIW, the generally accepted and documented platform tests include: #ifdef __sun /* this is SunOS */ #endif >> >> By the way, was it *actually* tested on SunOS 4? And if so, when and

[openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer

In crypto/mem_dbg.c, the type of static function pop_info() is to return an APP_INFO*. This pointer can be a dangling pointer, as can be seen in the following link as long as one assumes that line 382 is reachable (it is).

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> I'd like to propose the attached patch to 1.0.2d which avoids problems >> with strict ISO conforming compiler/options, which do not define 'sun' only >> '__sun' as usual... such as gcc/clang -std=c99 >> >> This affects the build itself, but also any user of openssl/opensslconf.h > > I've

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote: > I'd like to propose the attached patch to 1.0.2d which avoids problems > with strict ISO conforming compiler/options, which do not define 'sun' only > '__sun' as usual... such as gcc/clang -std=c99 > > This affects the build

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>>> I'd like to propose the attached patch to 1.0.2d which avoids problems >>> with strict ISO conforming compiler/options, which do not define 'sun' only >>> '__sun' as usual... such as gcc/clang -std=c99 >>> >>> This affects the build itself, but also any user of openssl/opensslconf.h >> >> I've

[openssl-dev] Building Open

Hi. I believe that I've found some issues while to build OpenSSL v1.0.2b for 64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015. There is a bug in the ms\do_win64a.bat OpenSSL batch file that causes some of the libraries to be built as 32-bit, to fix this you can do the

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>>> FWIW, the generally accepted and documented platform tests include: #ifdef __sun /* this is SunOS */ #endif >> >> By the way, was it *actually* tested on SunOS 4? And if so, when and >> with which compiler? Is it possible that it simply was harmonized at >> some point with

[openssl-dev] [openssl.org #4152] [PATCH] SRP code clean-up s_client and s_server

Hello, SRP is a secure password authentication / key exchange protocol. When the original SRP patches for OpenSSL were created by the EdelKey project back in 2000s, the highest version of TLS standard remained 1.0. Some code, however, if left unchanged, would by default restrict communications to

Re: [openssl-dev] Building Open

I believe that I've found some issues while to build OpenSSL v1.0.2b for 64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015. It appears that you skipped a step that was listed in INSTALL.W64, specifically perl Configure VC-WIN64A 1.0.2* builds normally for me on amd64 if