On Tue, Feb 19, 2019 at 09:28:36AM +0100, Claudio Jeker wrote:
> On Tue, Feb 19, 2019 at 12:10:25AM +0100, Andreas Kusalananda Kähäri wrote:
> > On Mon, Feb 18, 2019 at 10:11:03PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 18 Feb 2019 21:59:38 +0100
> > > > From: Claudio Jeker <cje...@diehard.n-r-g.com>
> > > >
> > > > In some places bgpd just wants something bigger then a 32bit int.
> > > > Instead of using int64_t or u_int64_t use (unsigned) long long which is
> > > > at
> > > > least 64bit and therefor good enough. Makes the mess with type
> > > > definition
> > > > of int64_t on various systems go away (including a bunch of type casts).
> > > > While there also apply the endian.h cleanup done in bgpd a few days ago.
> > > >
> > > > OK?
> > >
> > > You could use <stdint.h> and uint64_t instead. That should be
> > > portable. But you'd still need to be careful about printf statements
> > > since (u)int64_t might be (unsigned) long on some systems.
> >
> > printf should be no issue if you use the correct PRI*64 (PRIu64 or
> > PRId64) macro from <inttypes.h>. Both <stdint.h> and <inttypes.h> are
> > C99.
> >
> > E.g.
> >
> > uint64_t thing;
> >
> > /* ... */
> >
> > printf("The value is %" PRIu64 "\n", thing);
> >
> >
> > ... but I'm really not qualified to say anything about what you guys should
> > do.
> >
>
> While true I have to say that the PRI constructs are even worse than doing
> casts. Chopping up the format string like this is just ugly and unreadable
> for complex format strings.
Yes, and the only other alternative I can think of: (u)intmax_t and
%jd or %ju is not very attractive either.
-Otto
