From: Michael Kerrisk > Sent: 11 September 2020 10:31 > > Hi Alex, > > On 9/10/20 11:13 PM, Alejandro Colomar wrote: > > Signed-off-by: Alejandro Colomar <colomar.6.4.3@xxxxxxxxx> > > --- > > man3/inet_net_pton.3 | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/man3/inet_net_pton.3 b/man3/inet_net_pton.3 > > index 00f94b9d4..d74a33d74 100644 > > --- a/man3/inet_net_pton.3 > > +++ b/man3/inet_net_pton.3 > > @@ -332,6 +332,7 @@ Raw address: c1a80180 > > /* Link with "\-lresolv" */ > > > > #include <arpa/inet.h> > > +#include <inttypes.h> > > #include <stdio.h> > > #include <stdlib.h> > > > > @@ -381,7 +382,7 @@ main(int argc, char *argv[]) > > may not have been touched by inet_net_ntop(), and so will still > > have any initial value that was specified in argv[2]. */ > > > > - printf("Raw address: %x\en", htonl(addr.s_addr)); > > + printf("Raw address: %"PRIx32"\en", htonl(addr.s_addr)); > > > > exit(EXIT_SUCCESS); > > } > > So, I'm in a little bit of doubt about patches 01 and 02. Does > this really win us anything? On the one hand, %"PRIx32" is more > difficult to read than %x. On the other, does it win us anything > in terms of portability? At first glance, the answers seems to me > to be "no". Your thoughts? On 32bit systems uint32_t might be either 'int' or 'long'. So the format has to match - even though the ABI is probably the same in both cases. Mind you, htonl() itself could be problematic. On BE systems it is likely to be #define htonl(x) (x) so the type is whatever was passed. On LE systems it might even be long htonl(long) - which is its historic prototype. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)