[Dnsmasq-discuss] [PATCH] inet_addr and inet_aton replacement

Simon Kelley simon at thekelleys.org.uk
Tue Aug 10 21:55:25 UTC 2021


On 09/08/2021 15:14, Petr Menšík wrote:
> Hi,
> 
> some of our internal checking tools emit errors when the code is using
> outdated function with IPv4 only support. Because IPv6 build-time
> support is now required, I think using instead inet_pton would be better.
> 
> The first attached patch replaces inet_addr with proper error reporting
> function. I think this is without issues.
> 
> The second patch replaces inet_ntoa function with similar ntop. It
> contains more changes, because more recent function does not use
> internal hidden buffer but requires using external. I think
> daemon->addrbuff is used for this case usually. It brings more lines of
> code. It should also require more strict IP address format. Instead of
> "10.0", full "10.0.0.0" is required. It might refuse some weird
> configuration files. I think it is more correct.
> 
> Altough I have feeling some parts should be merged. For example
> log_packet from src/rfc2131.c is quite similar to log6_packet from
> src/rfc3315.c. They differ in address family handled and different
> function signatures. Only IPv4 variant forwards log to UBUS, I expect
> that is not intentional difference. I expect differences between
> protocols should be as minimal as possible.
> 
> What do you think, do those changes make sense?
> 

I think if I'd been doing this, I might have provided our_inet_ntoa()
which just wrapped inet_ntop() and declared a static buffer, but this is
better, if more work.

I moved the allocation of daemon->addrbuff into read_opts() so that is
can be used in the option code rather than the 127.127.127.127 local
variable, and deleted the commented out line about UBus. That call to
UBus is likely to go anyway.


Patches applied otherwise as-is.


Cheers,

Simon.




More information about the Dnsmasq-discuss mailing list