From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH 1/2] avoid using inet_ntoa()
Date: Thu, 10 Jun 2021 17:12:52 -0500 [thread overview]
Message-ID: <8d5a064e-b342-4fb8-ba4e-4f3ab9b2e0b4@gmail.com> (raw)
In-Reply-To: <CAJ6EMK3_SOd-ET_mSJE5ZHij99Sso-s4GxbMpefGzMBg8v7yVw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]
Hi Davide,
>> That would be unfortunate. I'm really not sure whether this needs to be 'fixed'
>> anyway. ell is meant for single-threaded, event driven apps. So our use of
>> inet_ntoa is just fine. In fact we do similar stuff all over the place.
>
> there's nothing wrong with using inet_ntoa() as long as the caller
> doesn't need to be "IPv6 friendly" and concurrency is not an issue.
> However,
> this would result in disabling the whole fedora "badfuncs" CI, that
> now is failing just because of inet_ntoa().
>
Is this a worthy goal in and of itself though? What other 'badfuncs' are there?
>>> At this point, probably the cleanest thing to do is to replace
>>> IP_STR() with a proper call to inet_ntop(), preceded by declaration of
>>> buf[INET_ADDRSTRLEN] (like it's already done in some hunks of this
>>> patch). Luckily, it's just 10 places (versus 6 users of inet_ntoa(),
>>> still looks feasible).
>>
>> Perhaps we can do something similar to MAC_STR instead?
>
> that's similar to the NIPQUAD / NIPQUAD_FMT thing that was done in
> Linux before the %pI4 format specified was introduced in printk (
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3685f25de1b0447fff381c420de
> ) :
>
> #include <stdio.h>
> #include <netinet/in.h>
> #include <arpa/inet.h>
>
> #define IP "%u.%u.%u.%u"
> #define IP_STR(uint_ip) ((unsigned char *) &uint_ip)[0], \
> ((unsigned char *) &uint_ip)[1], \
> ((unsigned char *) &uint_ip)[2], \
> ((unsigned char *) &uint_ip)[3]
>
> int main(int argc, const char *argv[])
> {
> struct in_addr ia = { .s_addr = 0x010200c0 };
> char buf[INET_ADDRSTRLEN];
>
> printf("test 0 %s\n", inet_ntoa(ia));
> printf("test 1 %s\n", inet_ntop(AF_INET, &ia, buf, INET_ADDRSTRLEN));
> printf("test 2 " IP "\n", IP_STR(ia.s_addr));
>
> return 0;
> }
>
I think this or something like this would be quite reasonable to use in / for
any debug messages where we print an ip.
>
>>> Il giorno lun 7 giu 2021 alle ore 20:41 Denis Kenzior
>>> <denkenz@gmail.com> ha scritto:
>>>>
>>>>> that might be useful for other future CLIENT_DEBUG() users.
>>>>>
>>>>
>>>> Fair enough, Wish there was a printf extension for ipv4 and ipv6 addresses like
>>>> printk uses... Oh well.
>>>
>>> yes, that would really make this game less boring :)
>>>
>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
>>> [2] https://github.com/shemminger/iproute2/blob/main/lib/utils.c#L980-L1020
>>>
>>
>> Yep, that's the other thing we can do. Just re-implement inet_ntoa or make our
>> own version that covers v4/v6 with a static buffer. Not sure that is any better
>> than just using inet_ntoa though ;)
>
> what about converting inet_ntoa() into inet_ntop(), and re-writing
> IP_STR() as above?
I guess that would be OK. We just have to remember to not use inet_ntoa in the
future...
Regards,
-Denis
next prev parent reply other threads:[~2021-06-10 22:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 9:50 [PATCH 0/2] avoid using inet_ntoa() and inet_aton() Davide Caratti
2021-06-03 9:50 ` [PATCH 1/2] avoid using inet_ntoa() Davide Caratti
2021-06-04 16:01 ` Denis Kenzior
2021-06-07 17:00 ` d. caratti
2021-06-07 18:41 ` Denis Kenzior
2021-06-08 12:46 ` d. caratti
2021-06-08 16:22 ` Denis Kenzior
2021-06-09 10:18 ` d. caratti
2021-06-10 22:12 ` Denis Kenzior [this message]
2021-06-03 9:50 ` [PATCH 2/2] avoid using inet_aton() Davide Caratti
2021-06-04 15:41 ` Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d5a064e-b342-4fb8-ba4e-4f3ab9b2e0b4@gmail.com \
--to=denkenz@gmail.com \
--cc=ell@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).