On Mon, Feb 18, 2019 at 02:24:52PM -0700, Theo de Raadt wrote: > Claudio Jeker <cje...@diehard.n-r-g.com> 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. > > > > This issue with int64_t being just a unsigned long on 64bit > > Huh? Surely you mispoke, it is not unsigned.
Arrrgg. int64_t -> long, u_int64_t aka uint64_t -> unsigned long Had too much type handling today. > linux is the > > problem I'm trying to avoid since the result is that all printf calls need > > casts. long long is %llu on all systems I care and so less ugly in this > > specific case. > > Huh? Again I'm confused. long long is %lld, not %llu Yes, that should have been %lld. Should have payed more attention while answering. -- :wq Claudio
