[Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

[Jose Fonseca]

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 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 they mean different things in 32- and 64-bit
> environments, which is rarely desired for integer literals.)

We're just gonna have to agree on disagreeing here.

I agree it's a matter of style. If people prefer using ULL I won't be 
nitpicking, but to me UINT64_C() seems more concise, and I'd like to be 
able to continue using it.

Anyway, I think we spent enough time on this already.

Jose


> On Tue, Jan 12, 2016 at 3:22 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> 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 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 <jfonseca at 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.gabbay at 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.gabbay at 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 at lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mesa-dev mailing list
>>>>>> mesa-dev at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>>>
>>>>>
>>>
>>