ell.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

  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).