On 12/01/16 08:29, Ilia Mirkin wrote:
I guess you didn't finish your thought -- but I don't think that
uint64_t and uint32_t are pointless -- they're very nice documentation
for variables.
Yeah, you're right, I meant to erase the paragraph. Must have typed undo
one time too less.
> But when
I guess you didn't finish your thought -- but I don't think that
uint64_t and uint32_t are pointless -- they're very nice documentation
for variables. But when assigning integer literals to them, IMO it's a
lot clearer to use the U, LL, and ULL suffixes. (Things like L and UL
are less useful since
But one of the very, very, very, very few:
include/c99/stdint.h:#define UINT64_C(val) val##ui64
include/c99/stdint.h:#define UINTMAX_C UINT64_C
src/gallium/drivers/llvmpipe/lp_query.c: td->frequency =
UINT64_C(10);
src/gallium/drivers/softpipe/sp_query.c: td->frequency =
UINT64_
Anyway, my point is that this is not a precendent. No idea why this
caused problems for Oded now. LLVM headers already requires
__STDC_CONSTANT_MACROS being defined.
Jose
And by your argument, it's pointless to use uint32_t because
On 12/01/16 08:15, Jose Fonseca wrote:
It's not the first
It's not the first time we use UINT64_C neither.
Jose
On 12/01/16 08:05, Ilia Mirkin wrote:
I think the number of things that would break if uint64_t and unsigned
long long were not, effectively, the same type, would be... huge. ULL
is a lot easier to read too, and has plenty of usage in mesa:
I think the number of things that would break if uint64_t and unsigned
long long were not, effectively, the same type, would be... huge. ULL
is a lot easier to read too, and has plenty of usage in mesa:
$ git grep -P -i '\dULL' | wc -l
302
An argument could be made that ULL could be 128-bit on so
The type of the resulting variable is `uint64_t` not `unsigned long long`.
To use ULL on constants one should also use `unsigned long long`
everywhere else in Mesa. Mixing uint64_t and unsigned long long seems
sloppy to me, as these types could potentially be different things on
different pla
On Mon, Jan 11, 2016 at 11:24 PM, Jose Fonseca wrote:
> On 11/01/16 21:07, Oded Gabbay wrote:
>>
>> The ISO C99 standard (7.18.4) specifies that C++
>> implementations should define UINT64_C only when
>> __STDC_CONSTANT_MACROS is defined.
>>
>> ecause we now use UINT64_C in our cpp files (since co
On 11/01/16 21:07, Oded Gabbay wrote:
The ISO C99 standard (7.18.4) specifies that C++
implementations should define UINT64_C only when
__STDC_CONSTANT_MACROS is defined.
ecause we now use UINT64_C in our cpp files (since commit
208bfc493debe0344d0b9cb93975981f14412628), we need to add this defi
On Mon, Jan 11, 2016 at 11:09 PM, Ilia Mirkin wrote:
> I'm not strictly opposed to passing this in, but... why not just fix
> it by removing that imho weird macro and instead use ULL suffix on
> literals?
Well, I thought about it, but because I didn't add that macro to the
code, I wanted a solutio
I'm not strictly opposed to passing this in, but... why not just fix
it by removing that imho weird macro and instead use ULL suffix on
literals?
On Mon, Jan 11, 2016 at 4:07 PM, Oded Gabbay wrote:
> The ISO C99 standard (7.18.4) specifies that C++
> implementations should define UINT64_C only wh
The ISO C99 standard (7.18.4) specifies that C++
implementations should define UINT64_C only when
__STDC_CONSTANT_MACROS is defined.
ecause we now use UINT64_C in our cpp files (since commit
208bfc493debe0344d0b9cb93975981f14412628), we need to add this define.
This also solves compilation errors
12 matches
Mail list logo
