On Wed, 26 Jun 2019, Uri Lublin wrote:
[...]
> > I'd very much prefer the cast to be in the expression rather than hidden
> > in some far away macro.
>
> Is that true even if the cast is needed in all the expressions
> that use this constant ?
Yes.
That's far from being the case though.
I count
>
> On Tue, 25 Jun 2019, Frediano Ziglio wrote:
> [...]
> > > uint64_t foo = 1234;
> > > spice_debug("foo=%" PRId64, foo / NSEC_PER_SEC);
> [...]
> > If you assume long long == 64 bit should not be a big problem
> > although you can still have the warning.
>
> Not a warning. A compilation
On 6/25/19 7:35 PM, Francois Gouget wrote:
On Tue, 25 Jun 2019, Frediano Ziglio wrote:
[...]
uint64_t foo = 1234;
spice_debug("foo=%" PRId64, foo / NSEC_PER_SEC);
[...]
If you assume long long == 64 bit should not be a big problem
although you can still have the warning.
So, we all
On Tue, 25 Jun 2019, Frediano Ziglio wrote:
[...]
> > uint64_t foo = 1234;
> > spice_debug("foo=%" PRId64, foo / NSEC_PER_SEC);
[...]
> If you assume long long == 64 bit should not be a big problem
> although you can still have the warning.
Not a warning. A compilation error:
CC g
>
>
> Uri Lublin wrote:
> > When the variable is 64 bit, you can use a 64bit macro for printing,
> > like PRId64.
>
> Wrong. Spice will fail to produce a 64 bit library if you add this
> anywhere:
>
> uint64_t foo = 1234;
> spice_debug("foo=%" PRId64, foo / NSEC_PER_SEC);
>
> Knowing t
Uri Lublin wrote:
> When the variable is 64 bit, you can use a 64bit macro for printing,
> like PRId64.
Wrong. Spice will fail to produce a 64 bit library if you add this
anywhere:
uint64_t foo = 1234;
spice_debug("foo=%" PRId64, foo / NSEC_PER_SEC);
Knowing that the variable is 64 bit
On 6/25/19 7:38 AM, Francois Gouget wrote:
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 l
>
> 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
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 a
> 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
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
>
> 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 overflo
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
13 matches
Mail list logo
