[Spice-devel] [spice v3] utils: Remove the LL suffix from NSEC_PER_SEC

[Frediano Ziglio]

> 
> On Mon, 17 Jun 2019, Uri Lublin wrote:
> 
> > On 6/15/19 2:59 PM, Frediano Ziglio wrote:
> > >>
> > >> This constant fits in a 32 bit signed integer so it does not need the
> > >> suffix. However some of the derived constants don't so use an uint64_t
> > >> cast to avoid the long vs long long confusion (such as in print
> > >> statements).
> > >> Also some of the expressions these constants are used in may overflow so
> > >> perform the appropriate casts in those locations. This makes it clearer
> > >> that these operations are 64 bit.
> > >>
> > >> Signed-off-by: Francois Gouget <fgouget at codeweavers.com>
> > > 
> > > ack for me, waiting Uri to confirm
> > 
> > Honestly, I do not see the value of making NSEC_PER_SEC a 32bit integer.
> > Most of its usage is in 64bit expressions.
> 
> It's not a 32 bit vs. 64 bit issue. It's a long vs. long long one.
> 

But in all architectures we support long long is 64 bit.
Technically is not long vs long long but int and long long.

> Whenever NSEC_PER_MILLISEC or NSEC_PER_SEC are used in a spice_debug()
> parameter one cannot use %u or %lu as the format. But not so for

Being signed you would use %lld or similars.

> NSEC_PER_MICROSEC or MSEC_PER_SEC. This is inconsistent so that timing

No, you cannot use long or not long for other constants too, they are
different for 32-bit so with both you cannot mix.

> traces require lots of guessing and recompilations.
> 

That's why we use -Wformat so compiler will tell you which ones are wrong.
I don't see why you need to guess and recompile, beside I suppose the
first time you are writing the code. And if you need to guess it means
you don't know the types you are using and so you are not sure about
overflows so you are not paying much attention to the code you are
writing.

Frediano