cURL / Mailing Lists / curl-library / Single Mail


Re: Sample code throws at execution

From: Daniel Stenberg <>
Date: Thu, 10 Dec 2009 20:06:48 +0100 (CET)

On Thu, 10 Dec 2009, Eric Schwarz wrote:

Please don't top-post. It is against our netiquette, which is suitably linked
to from every single mail posted to this list:

> As you know for sure to produce portable and quality code it should be
> possible to compile with different compilers since each brings up other
> errors and warnings as we see.

Our project is soon 12 years old. We've built (lib)curl on 40+ operating
systems on virtually every 32bit processor you can name. We've built it with
bascially all C compilers on those OS+CPU combos. There are few applications
or libraries that are more portable than libcurl.

And yes, we work all the time to minimize compiler warnings. We are
volunteer-driven with almost exclusively spare time contributions.

What exactly is your point with this?

> I doubt if there's a compiler out there which shows up all the leaks and
> warnings - enough for that.

Compilers very rarely show leaks.

> By the way I lack at the moment for a LINUX distribution and haven't got too
> much time to spend on that problem.

Right, but everyone else have heaps of time?

> It seems to me that there is a problem with the memory management indeed.

No, not in general.

> VS stops when executing in debug mode in file
> ..\curl-7.19.7\lib\hostthre.c at line 134
> Obviously there is a problem with the freeing of the memory.

What is the problem with that? It's a call to free() and the only place I can
see that pointer being assigned checks the return code from strdup() and fails
if it returns NULL. Is that not enough?

I don't have any Windows machine nor Windows development so I can't check and
I can't really fix this if it truly is a real problem.

See also KNOWN_BUGS #64, which might be related.

> Three possibilities come to my mind.

I can easily think of more possibilities, but that's not really helpful. Since
you can repeat the problem, can't you just set a break-point and see what the
situation is like?

> I would appreciate, Thomas, if you could back up your statement by the use
> of a tool like Valgrind you know for sure ( .

I'm not Thomas, but I would appreciate if you would just read up a bit about
our project and you should consider taking a slightly more humble and less
lecturing attitude here.

We run every test case many times every day with valgrind on a number of
different Linux distros.

But that's not helping you. Your remark is for code that is win32-specific so
valgrind won't detect anything at all in that area...

List admin:
Received on 2009-12-10