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)
