On 7/3/18 5:24 pm, Thomas Huth wrote: > On 07.03.2018 04:38, Alexey Kardashevskiy wrote: >> On 01/02/18 20:35, Alexey Kardashevskiy wrote: >>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru> >> >> Ping? >> >> >>> --- >>> slirp/arp_table.c | 4 ++-- >>> slirp/socket.c | 8 ++++---- >>> slirp/udp.c | 4 ++-- >>> 3 files changed, 8 insertions(+), 8 deletions(-) >>> >>> diff --git a/slirp/arp_table.c b/slirp/arp_table.c >>> index 3547043..bac608f 100644 >>> --- a/slirp/arp_table.c >>> +++ b/slirp/arp_table.c >>> @@ -33,7 +33,7 @@ void arp_table_add(Slirp *slirp, uint32_t ip_addr, >>> uint8_t ethaddr[ETH_ALEN]) >>> int i; >>> >>> DEBUG_CALL("arp_table_add"); >>> - DEBUG_ARG("ip = 0x%x", ip_addr); >>> + DEBUG_ARG("ip = %s", inet_ntoa(*(struct in_addr *)&ip_addr)); > > Is this endianness safe? The man-page of inet_ntoa says that the > function is expecting network byte order, so I wonder whether this works > right on both, big and little endian hosts?
arp_table_add() is called for either sin_addr (network order) or slirp_arphdr::ar_sip which is initialized from sin_addr (network order) with no order conversion. Bugs are still possible, of course :) -- Alexey