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 <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
