On Tue, Jun 5, 2012 at 4:35 AM, Jakob Bohm wrote:
> On 6/5/2012 6:19 AM, Zack Weinberg wrote:
>> According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the
>> last widely-used platform that crashed on free(NULL) was SunOS 4, which
>> "stopped being a reasonable portability target aro
On 6/5/2012 6:19 AM, Zack Weinberg wrote:
On 2012-06-04 8:10 PM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm
Having no current access to the C89 standard or its
drafts, I am relying on the experience that many "C89"
real world systems I have encountered di
On 2012-06-04 8:10 PM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm
Having no current access to the C89 standard or its
drafts, I am relying on the experience that many "C89"
real world systems I have encountered did not tolerate
free(NULL). In contrast all
> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm
> Sent: Tuesday, 29 May, 2012 03:34
> On 5/27/2012 2:29 AM, Jeremy Farrell wrote:
>
> Note that when considering portability, C99 is not yet
> fully implemented everywhere, so when I say "ANSI C"
> without qualification, I generally
On 5/29/2012 8:56 PM, Jeremy Farrell wrote:
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
Sent: Tuesday, May 29, 2012 8:34 AM
On 5/27/2012 2:29 AM, Jeremy Farrell wrote:
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
On 5/25/2012 5:30 PM, Ken Goldman wrote:
On 5/25/2012 3:33 AM, Jakob Bohm w
> From: Jakob Bohm [mailto:jb-open...@wisemo.com]
> Sent: Tuesday, May 29, 2012 8:34 AM
> On 5/27/2012 2:29 AM, Jeremy Farrell wrote:
> >> From: Jakob Bohm [mailto:jb-open...@wisemo.com]
> >> On 5/25/2012 5:30 PM, Ken Goldman wrote:
> >>> On 5/25/2012 3:33 AM, Jakob Bohm wrote:
> >>>
> ANSI C
> From: Jakob Bohm
> Which version of the ANSI Spec, and where did you get a copy?
>
> I have to rely on secondary sources and experience using various
> implementations that claim conformance.
I generally refer to Plauger's "The Standard C Library", where he quotes
the spec with commentary an
On 5/27/2012 2:29 AM, Jeremy Farrell wrote:
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
On 5/25/2012 5:30 PM, Ken Goldman wrote:
On 5/25/2012 3:33 AM, Jakob Bohm wrote:
ANSI C and POSIX free() is NOT required to handle free(NULL)
as a NOP.
I checked reputable sources (Plauger, Harbison an
Hi all,
> Which version of the ANSI Spec, and where did you get a copy?
>
> I have to rely on secondary sources and experience using
> various implementations that claim conformance.
Wikipedia http://en.wikipedia.org/wiki/ANSI_C is used to have
a link to a recent draft (free of charge) which is
(somewhat offtopic)
> From: owner-openssl-us...@openssl.org On Behalf Of Jeremy Farrell
> Sent: Saturday, 26 May, 2012 20:29
> > From: Jakob Bohm [mailto:jb-open...@wisemo.com]
> > Which version of the ANSI Spec, and where did you get a copy?
>
> I quoted from C99 in a recent message; can't re
> From: Jakob Bohm [mailto:jb-open...@wisemo.com]
> On 5/25/2012 5:30 PM, Ken Goldman wrote:
> > On 5/25/2012 3:33 AM, Jakob Bohm wrote:
> >
> >> ANSI C and POSIX free() is NOT required to handle free(NULL)
> >> as a NOP.
> >
> > I checked reputable sources (Plauger, Harbison and Steele, the ANSI
>
On 05/26/2012 12:28 PM, Jakob Bohm wrote:
> On 5/25/2012 5:30 PM, Ken Goldman wrote:
>> On 5/25/2012 3:33 AM, Jakob Bohm wrote:
>>
>>> ANSI C and POSIX free() is NOT required to handle free(NULL)
>>> as a NOP.
>>
>> I checked reputable sources (Plauger, Harbison and Steele, the ANSI
>> spec, and th
In message
on Fri, 25 May 2012 11:39:05 -0400, Jeffrey Walton said:
noloader> Perhaps I'm looking at the wrong free function (or I'm not
noloader> reading/deducing correct behavior), but it looks like a double free to
noloader> me:
noloader>
noloader> void CRYPTO_free(void *str)
noloader> {
no
On 5/25/2012 5:30 PM, Ken Goldman wrote:
On 5/25/2012 3:33 AM, Jakob Bohm wrote:
ANSI C and POSIX free() is NOT required to handle free(NULL)
as a NOP.
I checked reputable sources (Plauger, Harbison and Steele, the ANSI
spec, and the IEEE POSIX spec).
All agree that (e.g. ANSI)
"If ptr is
> From: Jakob Bohm [mailto:jb-open...@wisemo.com]
>
> On 5/25/2012 12:30 AM, Richard Levitte wrote:
> >
> > sudarshan.t.raghavan> I am assuming the default
> > sudarshan.t.raghavan> free routine ignores a NULL argument
> >
> > Your assumption is correct, OpenSSL expects the same semantics as
> >
Hi all!
> > If the library crashes on free(NULL), you're just making
> > people like me do this everywhere:
> >
> > if (ptr != NULL) free (ptr);
ok, if you have a test case "free (NULL)", agreed ;-)
Seems not all platforms conform to the "free(NULL) is a no-op".
I understand your example, thanks
On 5/25/2012 11:41 AM, Carter Browne wrote:
That's not the normal library behavior.
My typical design pattern is:
void *ptr = NULL;
do stuff which may in some branches allocate the pointer
free(ptr);
If the library crashes on free(NULL), you're just making people like me
do this everywhere:
On 5/25/2012 12:09 PM, Jeffrey Walton wrote:
My typical design pattern is:
void *ptr = NULL;
do stuff which may in some branches allocate the pointer
free(ptr);
This is very old, and has not evolved as security needs have changed
(forgive me if I read too much into it). For example, the ret
On Fri, May 25, 2012 at 11:25 AM, Ken Goldman wrote:
> On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
>>
>> I think crashing with NULL is quite good: a must-not-happen situation
>> leads to a defined dead of SIGSEGVs, at least for platforms supporting
>> that, typically with good aid for debuggin (
I agree. Passing NULL to a free function is most likely due to a bug. Given
that would you rather assert and find out the reason or ignore. I would
assume the defensive option would be to assert and analyze the core. My 2
cents.
Regards,
Sudarshan
On 25-May-2012 8:39 PM, "Steffen DETTMER"
wrote:
On 5/25/2012 11:25 AM, Ken Goldman wrote:
> On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
>>
>> I think crashing with NULL is quite good: a must-not-happen situation
>> leads to a defined dead of SIGSEGVs, at least for platforms supporting
>> that, typically with good aid for debuggin (like core fi
On Thu, May 24, 2012 at 8:16 AM, Sudarshan Raghavan
wrote:
> Hi,
>
> I am using CRYPTO_set_mem_functions to use our own custom memory
> routines in a non blocking proxy implementation. This was working fine
> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> routine is being invo
On 5/25/2012 3:33 AM, Jakob Bohm wrote:
ANSI C and POSIX free() is NOT required to handle free(NULL)
as a NOP.
I checked reputable sources (Plauger, Harbison and Steele, the ANSI
spec, and the IEEE POSIX spec).
All agree that (e.g. ANSI)
"If ptr is a null pointer, no action occurs."
___
On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
I think crashing with NULL is quite good: a must-not-happen situation
leads to a defined dead of SIGSEGVs, at least for platforms supporting
that, typically with good aid for debuggin (like core files or halting
debuggers providing a backtrace). Mayb
Hi all!
* Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM
> On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan
> wrote:
> > Ok, I can fix the custom free to take care of this.
> > But, why is this happening in openssl 1.0.1 and not in 1.0.0 or
> > 0.9.8?
>
> I thin
On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan
wrote:
> Ok, I can fix the custom free to take care of this. But, why is this
> happening in openssl 1.0.1 and not in 1.0.0 or 0.9.8?
I think the question to ask is why your code or library routines are
not validating parameters before operating
In message <4fbf35d0.3020...@wisemo.com> on Fri, 25 May 2012 09:33:36 +0200,
Jakob Bohm said:
jb-openssl> On 5/25/2012 12:30 AM, Richard Levitte wrote:
jb-openssl> > In
jb-openssl> >
message
jb-openssl> > on Thu, 24 May 2012 17:46:49 +0530, Sudarshan
jb-openssl> > Raghavan said:
jb-openssl> >
j
I can see this code in s3_lib.c
if (ctx->srp_ctx.login != NULL)
OPENSSL_free(ctx->srp_ctx.login);
while tls_srp.c does not have the NULL check before calling free. I
added the NULL check in tls_srp.c and I am not seeing the crash
anymore. Is this the fix or
I enabled debug symbols in openssl and this is what I am seeing
#3 0x0828bd74 in CUSTOM_FREE (oldMem=0x0) at ssl_mem.c:34
#4 0xb758e160 in CRYPTO_free (str=0x0) at mem.c:397
#5 0xb773520c in SSL_SRP_CTX_free (s=0xb3e4f300) at tls_srp.c:102
#6 0xb77091c0 in ssl3_free (s=0xb3e4f300) at s3_lib.c
Ok, I can fix the custom free to take care of this. But, why is this
happening in openssl 1.0.1 and not in 1.0.0 or 0.9.8? Is there is a
document or resource in the web that explains what is expected from
the custom alloc, realloc and free routines?
Regards,
Sudarshan
On Fri, May 25, 2012 at 4:00
On 5/25/2012 12:30 AM, Richard Levitte wrote:
In message on
Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan
said:
sudarshan.t.raghavan> Hi,
sudarshan.t.raghavan>
sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our own
custom memory
sudarshan.t.raghavan> routines in a
In message
on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan
said:
sudarshan.t.raghavan> Hi,
sudarshan.t.raghavan>
sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our own custom
memory
sudarshan.t.raghavan> routines in a non blocking proxy implementation. This was
work
On Thu, May 24, 2012, Sudarshan Raghavan wrote:
> Hi,
>
> I am using CRYPTO_set_mem_functions to use our own custom memory
> routines in a non blocking proxy implementation. This was working fine
> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> routine is being invoked with a
33 matches
Mail list logo
