Hi,

I found many uses of inet_ntoa() in the pound sources. Maybe this funktion is 
not thread save. From the manpage:

       The inet_ntoa() function converts the Internet host address in given in
       network  byte  order to a string in standard numbers-and-dots notation.
       The string is returned in a statically allocated buffer,  which  subse-
       quent calls will overwrite.

Using inet_ntop() shouldt be better. Is this correct?

tom anheyer

-- 
Tom Anheyer
BerlinOnline Stadtportal GmbH & Co. KG
D-10178 Berlin, Karl-Liebknecht-Straße 29
E-Mail: Tom.Anheyer(at)BerlinOnline.de
URL:    http://www.BerlinOnline.de/wir-ueber-uns/
Tel:    +49-30-2327-5210
Fax:    +49-30-2327-5596       

On Tuesday 05 October 2004 17.12, Tom Anheyer wrote:
> Hi,
>
> I found many uses of inet_ntoa() in the pound sources. Maybe this funktion
> is not thread save. From the manpage:
>
>        The inet_ntoa() function converts the Internet host address in given
> in network  byte  order to a string in standard numbers-and-dots notation.
> The string is returned in a statically allocated buffer,  which  subse-
> quent calls will overwrite.
>
> Using inet_ntop() shouldt be better. Is this correct?
>
> tom anheyer

You are right that inet_ntoa(3) is not thread-safe, but the issue is hardly 
critical - it is used exclusively for printing out stuff and it seems to work 
"well enough".

I would be happy to switch to inet_ntop(3), but I am not sure how widespread 
it is: at least on *BSD it seems to be part of the Linux compatability 
package. I don't really know about other systems, but I would be happy to 
hear from other list members: does YOUR system support it out of the box?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

> at least on *BSD it seems to be part of the Linux compatability
> hear from other list members: does YOUR system support it out of the box?

Just tried it on the FreeBSD 4.10 - inet_ntop seems to be working
right out of the box, w/o any linux compatibility layer turned on.

Sincerely,
Dmitry Dvoinikov
http://www.targeted.org/

--- Original message follows ---

> On Tuesday 05 October 2004 17.12, Tom Anheyer wrote:
>> Hi,
>>
>> I found many uses of inet_ntoa() in the pound sources. Maybe this funktion
>> is not thread save. From the manpage:
>>
>>        The inet_ntoa() function converts the Internet host address in given
>> in network  byte  order to a string in standard numbers-and-dots notation.
>> The string is returned in a statically allocated buffer,  which subse-
>> quent calls will overwrite.
>>
>> Using inet_ntop() shouldt be better. Is this correct?
>>
>> tom anheyer

> You are right that inet_ntoa(3) is not thread-safe, but the issue is hardly
> critical - it is used exclusively for printing out stuff and it seems to work
> "well enough".

> I would be happy to switch to inet_ntop(3), but I am not sure how widespread
> it is: at least on *BSD it seems to be part of the Linux compatability
> package. I don't really know about other systems, but I would be happy to
> hear from other list members: does YOUR system support it out of the box?

> Just tried it on the FreeBSD 4.10 - inet_ntop seems to be working
> right out of the box, w/o any linux compatibility layer turned on.

IMHO on OpenBSD 3.4 working too without linux compatibility...
The inet_ntop used in the base system:

# grep -rn inet_ntop /sbin/*
Binary file /sbin/dhclient matches
Binary file /sbin/dump matches
Binary file /sbin/ifconfig matches
... etc.



Jozsef Nemeth
Levnor Ltd.
Hungary

Robert Segall wrote:

> You are right that inet_ntoa(3) is not thread-safe, but the issue is hardly
> critical - it is used exclusively for printing out stuff and it seems to
work
> "well enough".

I disagree that this is unimportant.  If an implementation of inet_ntoa()
DOES use a static buffer, and it happens to be written to by one thread while
being read by another, there is the potential that the buffer might not be
NULL-terminated, causing pound to run off the end of the buffer while
printing
and possibly print garbage, cause a segfault, etc.

Now, I have never seen these problems occur under Linux, even with pound
under
heavy load with copious logging.  I believe this is because glibc includes
code to ensure that static buffers for functions such as gethostbyname() and
inet_ntoa() are created on a per-thread basis (as opposed to a single global
static buffer shared by all threads).  But it is possible that C libraries on
other platforms may not be so helpful about this matter, so I would recommend
considering the suggested changeover to inet_ntop().

Mark Fontana