svn commit: trunk/uClibc: extra/Configs include libc/inet

Ricard Wanderlof ricard.wanderlof at axis.com
Fri Jun 27 15:35:05 UTC 2008


On Fri, 27 Jun 2008, Bernhard Fischer wrote:

>>>> Added: trunk/uClibc/include/ifaddrs.h
>>>> ===================================================================
>>>> --- trunk/uClibc/include/ifaddrs.h                             (rev 0)
>>>> +++ trunk/uClibc/include/ifaddrs.h     2008-06-27 09:08:44 UTC (rev 22531)
>>>> @@ -0,0 +1,19 @@
>>>> +#ifndef _IFADDRS_H
>>>> +#include <libc/inet/ifaddrs.h>
>>>
>>> I'm not convinced that the above will work well.
>>> ...
>>
>> I propose to concatenate both include files to a single one and put it in
>> libc/inet, as the included definitions are only used there.
>
> That sounds better since it's just a private header that should not be 
> installed, yes.

Ok, I'll do that.

>>>> +    bool seen_ipv4;
>>>> +    bool seen_ipv6;
>>>
>>> yea, no. one variable and mask them. Or, even better
>>> unsigned __check_pf(void)
>>
>> Again, the reason this function looks like it does is because it was
>> snitched from glibc. That is probably not a strong enough reason not to
>> change it though ... ?
>
> I think that it's simple enough to provide a concise version that
> has identical functionality.

Agreed. I'll look into it.

> I would just try to set it to 1 in the else { s=socket() block, but it
> doesn't matter much if you rewrite __check_pf to just return the
> interresting bits.
>
> In the end this addrconfig thing just tries to
> ...
> so the __check_pf should either be manually inlined into it or you
> should try to inline it via keyword. I don't think it makes much sense
> to put __check_pf into a separate file, but that's just a cosmetic
> nitpick.

You are probably right, since we've changed the function so much we might 
as well change the way it is invoked.

>>> And please do not introduce warnings about using undefined preprocessor
>>> tokens and also keep in mind that we ultimately want a libc that can be
>>> configured as IPv6-only. Thanks.
>>
>> I assume you are referring to your comments above, or were there more
>> places that you were thinking of?
>
> Just the places above. Sorry if i was unclear.

Ok, I'll fix that asap so there are no build issues, then fix the rest 
after the weekend.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



More information about the uClibc mailing list