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(1000000000);
src/gallium/drivers/softpipe/sp_query.c: td->frequency =
UINT64_C(1000000000);
src/glsl/link_varyings.cpp: ((reserved_slots &
(UINT64_C(1) << *location / 4u) ||
src/glsl/link_varyings.cpp: (reserved_slots &
(UINT64_C(1) << slot_end / 4u))))) {
src/glsl/link_varyings.cpp: slots |= UINT64_C(1) << var_slot;
src/util/u_atomic_test.c:test_atomic(uint64_t, UINT64_C(0xffffffffffffffff))
On Tue, Jan 12, 2016 at 3:15 AM, Jose Fonseca <jfons...@vmware.com> wrote:
> 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:
>>
>> $ git grep -P -i '\dULL' | wc -l
>> 302
>>
>> An argument could be made that ULL could be 128-bit on some very
>> hypothetical configuration, but even in that case, it'd still work out
>> just fine. The key is that the constant is big enough to fit the
>> value, it's not a problem if it's bigger.
>>
>> On Tue, Jan 12, 2016 at 2:55 AM, Jose Fonseca <jfons...@vmware.com> wrote:
>>>
>>> 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 platform.
>>>
>>> We could use (uin64t_t)1, too, but it doesn't take any less typing than
>>> UINT64_C(1).
>>>
>>> Jose
>>>
>>>
>>> On 11/01/16 21:09, 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?
>>>>
>>>> On Mon, Jan 11, 2016 at 4:07 PM, Oded Gabbay <oded.gab...@gmail.com>
>>>> 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 define.
>>>>>
>>>>> This also solves compilation errors with GCC 4.8.x on ppc64le machines.
>>>>>
>>>>> Signed-off-by: Oded Gabbay <oded.gab...@gmail.com>
>>>>> ---
>>>>> configure.ac | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/configure.ac b/configure.ac
>>>>> index 9c3d1a3..8d19dab 100644
>>>>> --- a/configure.ac
>>>>> +++ b/configure.ac
>>>>> @@ -245,7 +245,7 @@ _SAVE_LDFLAGS="$LDFLAGS"
>>>>> _SAVE_CPPFLAGS="$CPPFLAGS"
>>>>>
>>>>> dnl Compiler macros
>>>>> -DEFINES="-D__STDC_LIMIT_MACROS"
>>>>> +DEFINES="-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS"
>>>>> AC_SUBST([DEFINES])
>>>>> case "$host_os" in
>>>>> linux*|*-gnu*|gnu*)
>>>>> --
>>>>> 2.5.0
>>>>>
>>>>> _______________________________________________
>>>>> mesa-dev mailing list
>>>>> mesa-dev@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
