chronos-tachyon / googletest-bazel

Fork of googletest that uses bazel.build
https://github.com/google/googletest
BSD 3-Clause "New" or "Revised" License
4 stars 4 forks source link

With 32-bit target, icc generates remarks about cast of void * to 64-bit integer in PrintTo #476

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
IMPORTANT NOTE: PLEASE send issues or requests to
http://groups.google.com/group/googletestframework *instead of here*.
This issue tracker is NOT regularly monitored.

If you really need to create a new issue, please provide the information
asked for below.

What steps will reproduce the problem?
1. Compile test source files against gmock-1.7.0 with icc 15 in 32-bit mode
2.
3.

What is the expected output? What do you see instead?

What is the expected output? What do you see instead?

The expected output is no remarks. I observe the following, one per source file 
with tests

../src/external/gmock-1.7.0/gtest/include/gtest/gtest-printers.h(326): remark 
#1195: conversion from integer to smaller pointer
        *os << reinterpret_cast<const void*>(
               ^
          detected during instantiation of "void testing::internal::PrintTo(const T &, std::ostream *) [with T=const void *]" at line 416

What version of Google Test are you using? On what operating system?

1.7.0. ubuntu 14.04 running under VMWare 6 (thus somehow not fully 64-bit 
compliant, at least as far as Intel's compiler is concerned)

Please provide any additional information below, such as a code snippet.

As we can see at 
https://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-pri
nters.h#324, the code is working around a limitation of old version(s) of gcc 
by casting a pointer non-portably to a 64-bit integer. The code runs fine, 
because the return cast makes things all OK, but icc doesn't look that far 
before making a remark.

uintptr_t is available from stdint.h/cstdint to solve this problem, but only in 
C99 and (generally) compilers that support C++03 (and more recent C++ 
flavours). There's no standard preprocessor macro for "how wide is a pointer?" 
or even "is this a 64-bit architecture?"

If there's interest, I could write a GTEST_HAS_STDINT that could use uintptr_t 
to handle this case, and perhaps future issues, in a way that is fully correct 
when the toolchain suports that header. GTEST_HAS_STDINT would have to default 
to be off, since even in C++11 providing cstdint header is optional.

Original issue reported on code.google.com by Mark.J.A...@gmail.com on 28 Sep 2014 at 1:41