Re: int64_t and printf

2011-06-05 Thread Poul-Henning Kamp
In message <4debf0e7.3040...@links.org>, Ben Laurie writes: >I note that you didn't react to my other wherein you cast from known >type A to known type B. I supposed it would be smart to also assert that >the cast was non-narrowing. Well, if casting to intmax_t is narrowing I think I have bigger

Re: int64_t and printf

2011-06-05 Thread Ben Laurie
On 05/06/2011 21:42, Poul-Henning Kamp wrote: > In message <4debe469.5060...@links.org>, Ben Laurie writes: >> On 05/06/2011 19:21, Poul-Henning Kamp wrote: >>> In message <4debc741.1020...@links.org>, Ben Laurie writes: > >>> I have therefore resorted to printf'ing any typedefed integer type usin

Re: int64_t and printf

2011-06-05 Thread Poul-Henning Kamp
In message <4debe469.5060...@links.org>, Ben Laurie writes: >On 05/06/2011 19:21, Poul-Henning Kamp wrote: >> In message <4debc741.1020...@links.org>, Ben Laurie writes: >> I have therefore resorted to printf'ing any typedefed integer type using >> "%jd" and an explicit cast to (intmax_t): >> >>

Re: int64_t and printf

2011-06-05 Thread Ben Laurie
On 05/06/2011 19:31, Sean C. Farley wrote: > On Sun, 5 Jun 2011, Ben Laurie wrote: > >> So, for example int64_t has no printf modifier I am aware of. Likewise >> its many friends. >> >> In the past I've handled this by having a define somewhere along the >> lines of... >> >> #if >> # define INT_6

Re: int64_t and printf

2011-06-05 Thread Ben Laurie
On 05/06/2011 19:21, Poul-Henning Kamp wrote: > In message <4debc741.1020...@links.org>, Ben Laurie writes: > >> So, for example int64_t has no printf modifier I am aware of. Likewise >> its many friends. > >> but I have no idea where to put such a thing in FreeBSD. Opinions? > > I have totally

Re: [RFC] Enabling invariant TSC timecounter on SMP

2011-06-05 Thread Andriy Gapon
on 03/06/2011 19:28 Jung-uk Kim said the following: > Unlike Intel, AMD did not guarantee "all TSCs reset to zero with RESET > IPI" before Bulldozer[1]. In fact, I tried to measure deltas between > cores when I started hacking on it using some crude heuristics, > somewhat like the OpenSolaris h

Re: int64_t and printf

2011-06-05 Thread Poul-Henning Kamp
In message <4debc741.1020...@links.org>, Ben Laurie writes: >So, for example int64_t has no printf modifier I am aware of. Likewise >its many friends. >but I have no idea where to put such a thing in FreeBSD. Opinions? I have totally given up on this mess. At best you get incredibly messy sour

Re: int64_t and printf

2011-06-05 Thread Jilles Tjoelker
On Sun, Jun 05, 2011 at 02:31:27PM -0400, Sean C. Farley wrote: > On Sun, 5 Jun 2011, Ben Laurie wrote: > > So, for example int64_t has no printf modifier I am aware of. Likewise > > its many friends. > > In the past I've handled this by having a define somewhere along the > > lines of... > > #

Re: int64_t and printf

2011-06-05 Thread mdf
On Sun, Jun 5, 2011 at 11:13 AM, Ben Laurie wrote: > So, for example int64_t has no printf modifier I am aware of. Likewise > its many friends. The worse option is to use the C99 defines, like PRI64 and PRI64U. The better option is to use %jd / %ju and cast the value to [u]intmax_t. Cheers, matt

Re: int64_t and printf

2011-06-05 Thread Sean C. Farley
On Sun, 5 Jun 2011, Ben Laurie wrote: So, for example int64_t has no printf modifier I am aware of. Likewise its many friends. In the past I've handled this by having a define somewhere along the lines of... #if # define INT_64_T_FMT "%ld" #else # define INT_64_T_FMT "%lld" #endif but I h

int64_t and printf

2011-06-05 Thread Ben Laurie
So, for example int64_t has no printf modifier I am aware of. Likewise its many friends. In the past I've handled this by having a define somewhere along the lines of... #if # define INT_64_T_FMT "%ld" #else # define INT_64_T_FMT "%lld" #endif but I have no idea where to put such a thing in Fre

Re: _LP64 and _ILP32

2011-06-05 Thread Warner Losh
On Jun 5, 2011, at 4:13 AM, Ben Laurie wrote: > On 05/06/2011 06:03, Warner Losh wrote: >> I'd add them for all !_LP64 architectures: arm, mips o32, mips n32, i386, >> and powerpc... > > Forgive the stupid question, but ... add them to what? If they aren't already defined by the compilers, thos

Re: _LP64 and _ILP32

2011-06-05 Thread Ben Laurie
On 05/06/2011 06:03, Warner Losh wrote: > I'd add them for all !_LP64 architectures: arm, mips o32, mips n32, i386, and > powerpc... Forgive the stupid question, but ... add them to what? > > Warner > > On Jun 4, 2011, at 2:41 PM, Ben Laurie wrote: > >> It turns out that both clang and gcc de

Re: sizeof(function pointer)

2011-06-05 Thread Robert Watson
On Tue, 31 May 2011, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The prob