cURL / Mailing Lists / curl-library / Single Mail


Re: Recent problems with ares and memdebug

From: Daniel Stenberg <>
Date: Wed, 18 Feb 2004 14:23:59 +0100 (CET)

On Wed, 18 Feb 2004, Tor Arntsen wrote:

> Ref.
> This fails because in lib/memdebug.h there's the following constructs:


> followed by a curl_accept that used to need 'struct sockaddr'.
> (NB: I know that Daniel just checked in a change to memdebug.h that removed
> that, just minutes ago. However, I'll argue for a more fundamental problem,
> if I may)

You certainly may! I'll add my 2 cents below...

> Now, because memdebug.h is included from ares, HAVE_SYS_TYPES_H and
> HAVE_SYS_SOCKET_H are not defined, as ares doesn't have a config.h.

Actually, it is because the configure script in ares doesn't check for those
header files. But anyway...

> This just happened to work on Linux, because Linux through some convoluted
> ways <bits/socket.h> would be included through Linux' <netinet/in.h> and
> <bits/socket.h> defines struct sockaddr on Linux.

Yeah, and I tend to do most of my everyday poking-around on Linux... Luckily
we have the auto-builds that turns red when I do bad moves like this!

> Wouldn't the best fix be to let ares/ get its own config.h, like src and
> lib? It runs its own ./configure script, after all.

It would. And then it could check for those header files and we should make
sure that config.h would be included properly where needed in the ares code.

I've just taken the easy way out of doing that. To avoid some work.

> ../../curl/lib/setup.h:117:30: curl/stdcheaders.h: No such file or directory
> This is also because ares doesn't have a config.h that can define
> STDC_HEADERS: (lib/setup.h)

Aha. I drew another conclusion (that we lacked the include path to the curl
header files, where that stdcheaders.h resides) but I was wrong and you are

> The above would fail everywhere, but just happens to work on e.g. my ia64
> builds (and, I suspect, on Daniel's linux+debug+ares builds), because curl
> is also installed as a system library, and thus there exists a file
> /usr/include/curl/stdcheaders.h which is picked (incorrectly) by the build!

Yes, you're right. Dammit those distros ship curl! ;-P

You feel like making a patch for ares?

> Again, that could also be fixed if ares had its own config.h file I think.

The inclusion of memdebug.h within ares is in itself a somewhat "ugly" move,
since memdebug.h was designed to be a libcurl-internal header and was never
intended as a more generic memory debug header. The reason I still want to do
it, is that it is the shortest route to get full memory tracking/debugging of
all the functions libcurl use in ares as well, making it less likely that we
introduce memory leaks while developing.

    Daniel Stenberg -- --
   [[ Do not send mails to this email address. They won't reach me. ]]
Received on 2004-02-18