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 they mean different things in 32- and 64-bit environments, which is rarely desired for integer literals.)
On Tue, Jan 12, 2016 at 3:22 AM, Jose Fonseca <jfons...@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 <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