RE: [PATCH 01/24] inet_net_pton.3: Use 'PRIx32' rather than "%x" when printing 'uint32_t' values

[David Laight]

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)