We need to document the usage of GTEST_HAS_* macros, as they are in the
public API.

What steps will reproduce the problem?
1. configure and make gtest
2. run make check

What is the expected output? What do you see instead?
I expect the tests to pass. Instead I see the following output
---SNIP---
test/gtest_repeat_test.cc: In member function 'virtual
void<unnamed>::BarDeathTest_ThreadSafeAndFast_Test::TestBody()':
test/gtest_repeat_test.cc:114: error: 'EXPECT_DEATH' was not declared in
this scope
make[1]: *** [test/gtest_repeat_test.o] Error 1
make: *** [check-am] Error 2
---/SNIP---

What version of the product are you using? On what operating system?
gtest-1.0.0
Mac OS X 10.4.11


Please provide any additional information below.
I have attached a patch which causes all tests to pass on this machine. I
tested the patch on my Google corp workstation as well. All tests pass
there, including BarDeathTest.ThreadSafeAndFast.

This would help with creating 'configure' scripts using autoconf tools.

In particular, the macro 'AC_CHECK_LIB' requires the name of an exported
function.  This function is used to check that the library is available and
can be linked.  The function can be very simple, and serves only as a
public identifier for checking linkage.

For example:

extern "C" char const* gtest_version_cstr()
{
  static char const msg[] = "googletest 1.0.0";
  return msg;
}

Then, in 'configure.ac':

AC_CHECK_LIB( [gtest], [gtest_version_cstr] )

Some users don't use RTTI in their build.  For example, they pass -fno-rtti
to gcc.  Google Test's typed tests use RTTI and thus won't compile here. 
To make it work for such users, Google Test provides the GTEST_HAS_RTTI
macro for the user to define.  However there's no automated test to verify
this.  Please add one.

What steps will reproduce the problem?
1. Download gtest
2. Follow steps to upgrade solution/projects to VS2008
3. Create a new console application in VS2008
4. Add references to the gtest library/include files
5. Add the statement to run all google tests.

Instead of a successful build, you may receive a LNK2005 error in VS2008.

This happened to me as I was attempting to adopt Google test for our MFC-
based project.  I was able to solve the problem and wanted to post it here 
for others.

The following article provides additional information on LNK2005 errors.
http://cubicspot.blogspot.com/2007/06/solving-pesky-lnk2005-errors.html

Option #2 fixed my issue.  In "Properties..." under "C++->Code Generation-
>Runtime Library" Multi-threaded(/MT) was selected for the Release build 
and Multi-Threaded Debug (/MTd) was selected for the Debug build.  My 
project was set to Multi-threaded DLL (/MD) and Multi-threaded Debug DLL 
(/MDd) respectively.  Any mismatch has the potential to cause this error.

I am not an expert on the subject by any means, but wanted to provide what 
I know for others that may experience the issue.

What version of the product are you using? On what operating system?

svn revision 78
SunOS dev01-mel 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440
CC: Sun C++ 5.8 Patch 121017-11 2007/05/02

Please provide any additional information below.

The following patch fixes it for me.

Index: test/gtest-filepath_test.cc
===================================================================
--- test/gtest-filepath_test.cc (revision 78)
+++ test/gtest-filepath_test.cc (working copy)
@@ -61,6 +61,11 @@
 #define PATH_SEP "/"
 #endif  // GTEST_OS_WINDOWS

+
+#ifdef GTEST_OS_SUN
+#include <unistd.h>
+#endif  // GTEST_OS_SUN
+
 namespace testing {
 namespace internal {
 namespace {
Index: test/gtest_break_on_failure_unittest.py
===================================================================
--- test/gtest_break_on_failure_unittest.py (revision 78)
+++ test/gtest_break_on_failure_unittest.py (working copy)
@@ -81,7 +81,7 @@
   # On Unix-like systems, the lowest 8 bits of the exit code is the
   # signal number that killed the process (or 0 if it wasn't killed by
   # a signal).
-  return (exit_code & 255) != 0
+  return (exit_code>>8) == (signal.SIGSEGV + 128)


 # The unit test.
Index: include/gtest/internal/gtest-port.h
===================================================================
--- include/gtest/internal/gtest-port.h (revision 78)
+++ include/gtest/internal/gtest-port.h (working copy)
@@ -145,6 +145,11 @@
 #define GTEST_OS_MAC
 #elif defined __linux__
 #define GTEST_OS_LINUX
+#elif defined __sun
+// TODO([email protected]): GTEST_OS_SUN is currently used to mean both "The
+// OS is Solaris" and "The compiler is Sunpro". These meanings should
really be
+// separated in order to better support Solaris compilers other than Sunpro.
+#define GTEST_OS_SUN
 #endif  // _MSC_VER

 // Determines whether ::std::string and ::string are available.
@@ -249,7 +254,7 @@
 //   struct Foo {
 //     Foo() { ... }
 //   } GTEST_ATTRIBUTE_UNUSED;
-#if defined(__GNUC__) && !defined(COMPILER_ICC)
+#if defined(__GNUC__) && !defined(COMPILER_ICC) || defined(GTEST_OS_SUN)
 #define GTEST_ATTRIBUTE_UNUSED __attribute__ ((unused))
 #else
 #define GTEST_ATTRIBUTE_UNUSED

There doesn't seem to be good memory leak detection (or any at all). 
What would be nice is if there's a way to save the heap and stack memory
address before the test, and then compare the heap and stack memory
addresses after end of the test fixture and check for any memory leaks.
This doesn't seem to be happening.

Some GTEST_* macros have two states: defined vs undefined, e.g. 
GTEST_OS_MAC.  Some GTEST_* macros have either 0 or 1 values, e.g. 
GTEST_IS_THREADSAFE.  Try to use the same convention across the board.

On Mac OS X(at least 10.4+) "libtoolize -c" is replaced by "glibtoolize -c".

Exception testing macros would be useful for many people, especially on 
Windows where hard to avoid exceptions.

Required macros:
EXPECT_THROW(Expression, ExpectedExceptionType)
ASSERT_THROW(Expression, ExpectedExceptionType)
EXPECT_NO_THROW(Expression)
ASSERT_NO_THROW(Expression)

Where  *_THROW asserts that the given expression throws an exception of 
the specified type, while *_NO_THROW asserts that the given expression 
does not throw any exception at all.

We need to implement functions to capture statndard/error output to
facilitate testing of code sending information there. Suggested names:
void CaptureTestStdout() - starts interception of text output to standard
output
string GetCapturedTestStdout() - terminates stdout capture and returns
captured text in a string
void CaptureTestStderr() - starts interception of text output to standard
error output
string GetCapturedTestStderr() - terminates stderr capture and returns
captured text in a string

Google Test's XML report format differs from JUnit's slightly.  While we
cannot change it without breaking some existing processes, a quick
short-term solution is to write an XSLT to convert
Google Test's output to JUnit's format (it's also very flexible in
case JUnit changes its format).  In the long run, we could extend the
--gtest_output flag with an option to use the JUnit format, e.g.

 --gtest_output=junit_xml

instead of

 --gtest_output=xml

This will be more work to implement but is easier for the users.

Macros don't respect namespaces, so it is sometimes hard for a user to tell
whether a Google Test macro is public or not.

To reduce the likelihood of a user accidentally depend on Google Test's
internal implementation, we should name all internal macros *_ (i.e. ending
with an underscore).

I tried to do:

  class Foo { };
  class Bar
  {
  private:
    Foo* m_foo;
  public:
    Bar() : m_foo(0) { }
    Foo* foo(void) { return m_foo; }
  }
  Bar baz;

  EXPECT_EQ(0, baz.foo());

This didn't work until I did this:

  EXPECT_EQ((void*)0, baz.foo());

Because we deal with enough pointers in our code, I've implemented 
{ASSERT|EXPECT}_NULL and {ASSERT|EXPECT}_NOT_NULL. The attached diff 
implements this entirely in <gtest/gtest.h>.

gtest needs a univeral binary framework for Mac OS X. I propose adding an Xcode 
project to build 
the framework.

Requirements section in README file
(http://code.google.com/p/googletest/source/browse/trunk/README) doesn't
list requirements for building gtest under Cygwin. The necessary packages
include:
* libtool, automake, and autoconf for configuring builds out of svn
* gcc, make, and python for building gtest

Currently, the README file lists only Cygwin version required for building.

What steps will reproduce the problem?
1.
main.cpp
-------- 
bool ThrowAnException()
{
  throw 0;
}
TEST(Test, Exception) 
{ 
  EXPECT_TRUE(ThrowAnException());
}

../main.cpp
-----------
int main(int argc, char **argv) {
  std::cout << "Running main() from gtest_main.cc\n";

  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}


2.   g++ -o main main.cpp ../main.cpp ../lib/libgtest.a -I../include
3. ./main

What is the expected output? What do you see instead?
I expected the same as in Issue 16.

~/tests/test$ ./main
Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Test
[ RUN      ] Test.Exception
terminate called after throwing an instance of 'int'
Aborted

What version of the product are you using? On what operating system?
Just checked out the svn trunk at a Debian GNU/Linux

Please provide any additional information below.
It happened to me while testing googletest in another project but I
simplified to this

What steps will reproduce the problem?
1. Compilation of unit tests
2.
3.

What is the expected output? What do you see instead?
During linking the following error occurred.
$ make check
...
g++ -g -O2 -o samples/.libs/sample1_unittest samples/sample1_unittest.o 
-L/home/emst/gtest-1.0.1/lib/.libs -Llib/.libs -lgtest_main -lgtest
-L/home/mape/downloads/gcc-3.4.4/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src
-L/home/mape/downloads/gcc-3.4.4/powerpc-ibm-aix5.2.0.0/libstdc++-v3/src/.libs
-L/home/mape/downloads/gcc-3.4.4/gcc -L/usr/local/lib
samples/.libs/libsamples.a
-Wl,-blibpath:/usr/local//lib:/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.4:/u
sr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.4/../../..:/usr/lib:/lib
ld: 0711-317 ERROR: Undefined symbol: typeinfo for testing::Test
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make[1]: *** [samples/sample1_unittest] Fel 1
make[1]: Leaving directory `/home/emst/gtest-1.0.1'
make: *** [check-am] Fel 2


What version of the product are you using? On what operating system?
gtest-1.0.1

[emst@aix1 gtest-1.0.1]$ uname -a
AIX aix1 2 5 0056687F4C00

[emst@aix1 gtest-1.0.1]$ gcc --version
gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Please provide any additional information below.
From my understanding this is related to virtual functions and some entries
in the vnode table not being generated due to non implemented virtual
functions. But we tried to add an empty body to all virtual functions in
testing::Test but it didn't make a difference.

We later found a workaround that is to compile the unit tests with the flag
-fno-rtti for GCC. After that the linking goes fine and the tests can be run.

1. Converted your sln to VS2008
2. Only gtest and gtest_environment_test build without errors
3. All other projects have unresolved externals

gtest 1.0.1. on 64-bit Vista with Visual Studio 2008 Professional

We should create a cheat sheet that can be printed on A4 or letter-sized
paper.  To ensure the formatting and allow integration between different
tags/branches, the source file should be in the LaTeX format, from which
PDF can be easily generated.

Google Test doesn't depend on exceptions, so the ASSERT_* macros will
return from the current function when they failed.  This is all right
normally.  However, if your test calls a sub-routine that has an
ASSERT_* failure in it, your test will continue after the sub-routine
returns.  This may not be what you want.

To solve this, you can write

 Foo();  // This may generate an ASSERT_* failure.
 if (HasFatalFailure()) return;

where HasFatalFailure() is a static method of Google Test's
testing::Test class.  However this doesn't tell you which sub-routine
caused the problem when you call multiple of them in the same test.

After discussions with Googlers Bob Sidebotham and Matt Frantz, I'd
like to propose the following macro (the idea is mostly theirs):

 ASSERT_NO_FATAL_FAILURE(statement);

will execute 'statement' and assert that it doesn't generate any *new*
ASSERT_* failures.  If it does, Google Test will print a failure
message with the source text of 'statement' in it, and return from the
current function.

Normally you'll use ASSERT_NO_FATAL_FAILURE() when the inner-statement
is a call to a sub-routine.

For consistency, we'll also add an EXPECT_NO_FATAL_FAILURE(statement)
to match.

hello!

What steps will reproduce the problem?
1.I used vs2005 build a vc project. The project static-link 'gtest.lib' , 
when i compiler , IDE prompt many link-errors( like : "error 
LNK2005: "public: __thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::~basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@XZ) has defined in msvcprtd.lib(MSVCP80D.dll)"

What version of the product are you using? On what operating system?
1.0.1

thanks;

C++ often requires you to explicitly cast NULL to a specific type when it
is used to invoke a function template, which is tedious.  We can add the
following class:

class Null {
 public:
  template <typename T>
  operator T*() const { return NULL; }
};

Then the user should be able to write Null() wherever a NULL pointer is
expected, even when invoking a templatized function.

include/gtest/internal/gtest-type-util.h is generated from
gtest-type-util.h.pump using the 'pump' script, which hasn't been polished
enough to release yet.  We should release the script and its documentation.

Reported by Juanjo:

The only problem I found so far is that there are no death tests for
OS X. I know that we do not have clone and that fork by itself is not
thread safe, but my library is also not thread safe and, lacking
exceptions by design, relies on abort()/exit() for signalling errors.

I have come up with a simple solution which consists on activating
death tests but not implementing the ExecDeath... class. Furthermore,
in order to avoid those annoying warnings (couldn't you just print
them once?) about the thread number, I have implemented also
GetThreadCount() for OS X.

The code is very simple and since it may be useful for somebody else,
I have attached it to the end of this message. Please consider
including a variant of it in the next release

Juanjo

Index: include/gtest/internal/gtest-port.h
===================================================================
--- include/gtest/internal/gtest-port.h (revision 83)
+++ include/gtest/internal/gtest-port.h (working copy)
@@ -213,7 +213,7 @@
 #endif  // GTEST_HAS_STD_STRING

 // Determines whether to support death tests.
-#if GTEST_HAS_STD_STRING && defined(GTEST_OS_LINUX)
+#if GTEST_HAS_STD_STRING && (defined(GTEST_OS_LINUX) ||
defined(GTEST_OS_MAC))
 #define GTEST_HAS_DEATH_TEST
 // On some platforms, <regex.h> needs someone to define size_t, and
 // won't compile otherwise.  We can #include it here as we already
@@ -464,7 +464,7 @@

 // There's no portable way to detect the number of threads, so we
just
 // return 0 to indicate that we cannot detect it.
-inline size_t GetThreadCount() { return 0; }
+size_t GetThreadCount();

 // Defines tr1::is_pointer (only needed for Symbian).

Index: src/gtest-death-test.cc
===================================================================
--- src/gtest-death-test.cc     (revision 83)
+++ src/gtest-death-test.cc     (working copy)
@@ -38,6 +38,13 @@
 #include <errno.h>
 #include <limits.h>
 #include <stdarg.h>
+#include <unistd.h>
+extern "C" char **environ;
+#include <sys/types.h>
+#include <sys/mman.h>
+#ifndef MAP_ANONYMOUS
+# define MAP_ANONYMOUS MAP_ANON
+#endif
 #endif  // GTEST_HAS_DEATH_TEST

 #include <gtest/gtest-message.h>
@@ -538,6 +545,8 @@
  std::vector<char*> args_;
 };

+#ifdef GTEST_OS_LINUX
+
 // A struct that encompasses the arguments to the child process of a
 // threadsafe-style death test process.
 struct ExecDeathTestArgs {
@@ -639,6 +648,8 @@
  return OVERSEE_TEST;
 }

+#endif // !GTEST_OS_LINUX
+
 // Creates a concrete DeathTest-derived class that depends on the
 // --gtest_death_test_style flag, and sets the pointer pointed to
 // by the "test" argument to its address.  If the test should be
@@ -669,7 +680,11 @@
  }

  if (GTEST_FLAG(death_test_style) == "threadsafe") {
+#ifdef GTEST_OS_LINUX
    *test = new ExecDeathTest(statement, regex, file, line);
+#else
+    *test = new NoExecDeathTest(statement, regex);
+#endif
  } else if (GTEST_FLAG(death_test_style) == "fast") {
    *test = new NoExecDeathTest(statement, regex);
  } else {
Index: src/gtest-port.cc
===================================================================
--- src/gtest-port.cc   (revision 83)
+++ src/gtest-port.cc   (working copy)
@@ -47,6 +47,10 @@
 #include <gtest/gtest-message.h>
 #include <gtest/internal/gtest-string.h>

+#ifdef GTEST_OS_MAC
+#include <mach/mach_init.h>
+#include <mach/task.h>
+#endif

 namespace testing {
 namespace internal {
@@ -55,6 +59,20 @@

 // Implements RE.  Currently only needed for death tests.

+#ifdef GTEST_OS_MAC
+size_t GetThreadCount() {
+  mach_msg_type_number_t thread_count;
+  thread_act_port_array_t thread_list;
+  task_t task = current_task();
+  task_threads(task, &thread_list, &thread_count);
+  return thread_count;
+}
+#else
+size_t GetThreadCount() {
+  return 0;
+}
+#endif // !GTEST_OS_MAC
+
 RE::~RE() {
  regfree(&regex_);
  free(const_cast<char*>(pattern_));

What steps will reproduce the problem?
1. compile sample2.cc with Visual Studio 2005

Output from compiler is:

cc(52) : warning C4996: 'strcpy' was declared deprecated
        c:\program files\microsoft visual studio 8\vc\include\string.h(73) : see declaration of 'strcpy'
        Message: 'This function or variable may be unsafe. Consider using strcpy_s instead. To disable 
deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'

I don't want to have to #define _CRT_SECURE_NO_DEPRECATE

What steps will reproduce the problem?
1. Create a failing test
2. Run the test in Microsoft Visual Studio

What is the expected output?
unittest.cc(107): error: Value of: false
  Actual: false
Expected: true

What do you see instead?
unittest.cc:107: Failure
Value of: GTEST_IS_NULL_LITERAL(1)
  Actual: false
Expected: true

What version of the product are you using? On what operating system?
1.0.0
Windows
Visual Studio 2005

Please provide any additional information below.
Currently the PrettyUnitTestResultPrinter prints failures in this 
format: "FILE:LINE: Failure", while MSVC expects this format: 
"FILE(LINE): error: ..."!

I've created a patch which uses the correct format iff _MSC_VER defined.

GoogleTestPrimer talks about how to write the main() function, but it fails
to mention that Googletest provides an appropriate version of main in its
gtest_main project.

Currently they use strcasecmp which is defined only for POSIX (or C) locale
in POSIX standard. We need consistent behavior across platforms to test for
internationalized code. strcoll might be appropriate to use.

If you have:

  class Exception { };
  void foo(void) { throw new Exception(); }
  EXPECT_THROW(foo(), Exception);

The report will say that Exception was not thrown. This is because the
GTEST_TEST_THROW only catches "expected_exception const&" instead of also
considering "expected_exception const*".

It may be bad style to throw a pointer to an exception, but there's a lot
of legacy code out there that uses "throw new Exception()" instead of
simply "throw Exception()".

The following patch fixes this, and prevents a memory leak in the case of
pointers to exception.

====
//depot/agent/main/ThirdPartySource/gtest/1.1.0/include/gtest/internal/gtest-int
ernal.h#1
-
C:\depot\agent\main\ThirdPartySource\gtest\1.1.0\include\gtest\internal\gtest-in
ternal.h
====
@@ -728,6 +728,10 @@
     catch (expected_exception const&) { \
       gtest_caught_expected = true; \
     } \
+    catch (expected_exception const* expected_exception_const_pointer) { \
+      delete expected_exception_const_pointer;
+      gtest_caught_expected = true; \
+    } \
     catch (...) { \
       gtest_msg = "Expected: " #statement " throws an exception of type " \
                   #expected_exception ".\n  Actual: it throws a different " \

andy.bache _at_ googlemail.com suggested:

"I have just got started with Google C++ Testing Framework and was
wondering if anyone had built or is planning to build a Google C++
Tests Add In for Visual Studio.  I have used the NUnit add in with the
#Develop IDE.  It runs all the tests as part of build process and
displays the results on a panel within the IDE.

I have been away from C++ for a little while and have just returned to
developing in C++ with Visual Studio and am trying to get a Unit Test
framework in place.  I like the look of google tests but having it
better integrated with the IDE would be helpful.

Using the post build step to kick off unit tests is a good start but
it would be better to have the results integrated in the IDE.

I guess that I could write my own Visual Studio Add In - possibly
parsing the XML results file and displaying the results in the IDE but
I have never written on before so that would quite a bit of time and
effort and I would hate to do it if someone else already has and made
a good job of it.

If you know of anything like this or also think it would be useful get
back to me.

Cheers,"

I replied:

"Hi Andy,

Thanks for the suggestion!  I think this will be something very nice to 
have.

Unfortunately I don't know how to write a VS add-in either, and my
hands are full (actually more than full).  Therefore I hope you or
someone interested could take the challenge to implement it and share
the result with the rest of us.  Cheers!"

The user doesn't expect that failures from other threads may change the
result of EXPECT_{,NON}FATAL_FAILURE.

We also want to be consistent with how EXPECT_NO_FATAL_FAILURE handles
failures from other threads.
http://code.google.com/p/googletest/issues/detail?id=23

The GoogleTestAdvancedGuide page in the wiki documents an environment
variable / command line switch to cause test timings to be printed.

This switch is not implemented in the Google Test library.

It would be useful to have.

It would be nice to have an Eclipse plug-in for Google Test.

Josha at industrial logic has done some work here.

Such information is available in the XML report but not in the text output.
 We should add a --gtest_print_time flag for including timing info in the
text output. 

What steps will reproduce the problem?
1. Download 1.0.0 release of gtest
2. Unpack to a directory
3. Run ./configure
4. Run make

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

There should be no errors compiling but I get the following:

depbase=`echo src/gtest.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
        if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I. -I./config_aux  -I. -I./include   -g -O2 -MT src/gtest.lo -MD -MP
-MF "$depbase.Tpo" -c -o src/gtest.lo src/gtest.cc; \
        then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f
"$depbase.Tpo"; exit 1; fi
mkdir src/.libs
 g++ -DHAVE_CONFIG_H -I. -I. -I./config_aux -I. -I./include -g -O2 -MT
src/gtest.lo -MD -MP -MF src/.deps/gtest.Tpo -c src/gtest.cc  -fno-common
-DPIC -o src/.libs/gtest.o
In file included from src/gtest.cc:34:
./include/gtest/gtest.h:74:39: error: gtest-internal.h: No such file or
directory
In file included from ./include/gtest/gtest.h:75,
                 from src/gtest.cc:34:
./include/gtest/gtest-message.h:57:37: error: gtest-string.h: No such file
or directory
make: *** [src/gtest.lo] Error 1


What version of the product are you using? On what operating system?

gtest: 1.0.0
Mac OS X: 10.5.4

Please provide any additional information below.

The problem is solved if instead of ./configure I use ./configure
CPPFLAGS=-DGTEST_NOT_MAC_FRAMEWORK_MODE. Users should just be able to
./configure && make and have it work out of the box.

Currently, our users have to type the following command after downloading
the source from svn:
aclocal && libtoolize -c && autoheader && automake -ac && autoconf
(aclocal >= 1.9 && automake >= 1.9)

We should provide a script to perform this sequence.

The initial release of Google Test contains autotools-based build scripts.
 We need to add support for Windows and Mac OS X. 

Google Test should support tests that are parameterized by:

- a set of values,
- a set of implementations of the same interface (in the inheritance
sense), and
- a set of types/values for instantiating some templates.

The above goals may require different constructs.

On Fri, Sep 12, 2008 at 3:12 PM, balazs.dan <[email protected]> wrote:
>
> Hello guys,
>
> I've run gtest_unittest on a Hungarian Windows and these tests failed:
> EXPECT_HRESULT_SUCCEEDED
> ASSERT_HRESULT_SUCCEEDED
> EXPECT_HRESULT_FAILED
> ASSERT_HRESULT_FAILED
> The reason is gtest_unittest tests error messages also and these
> messages are localized on windows.
>
> I'm not sure it is a real issue or not, but better to know this
> thing..

Thanks for the report!  I believe this only indicates that the tests
aren't portable, and the assertions themselves should be sound.  The
tests for the error messages aren't really critical,and it would be
too much hassle to localize them, so I think we'll just disable these
tests.

src/gtest-filepath.cc: In static member function 'static
testing::internal::FilePath testing::internal::FilePath::GetCurrentDir()':
src/gtest-filepath.cc:82: error: 'PATH_MAX' was not declared in this scope
src/gtest-filepath.cc:83: error: 'cwd' was not declared in this scope
make: *** [src/gtest-filepath.lo] Error 1

I added #include <limits.h>, which fixed the problem.

Thread-safe death tests currently don't search the PATH when re-executing
the test program.  This means the user cannot put a test binary that
contains thread-safe death tests in a directory in the PATH and invoke it
without a directory prefix.

This is rarely a problem in practice (hence the low priority), as:

- people rarely leave tests in PATH - that's arguably not a good idea.
- more people use the "fast" style death tests, which don't have this problem.

Just for future reference, Mike Burrows suggested the following
impelementation:

In the forked process, you may not call getenv() (which execvp does,
for example),
and you may not call malloc(), but you can do these things before forking.
Below is an untested example.


Mike


#include <unistd.h>

/* exec() the first file possible that is called name[] and is on the colon
  separated path path[], with the argument in argv[].
  The path is ignored if name[] contains a slash.
  Requires that buffer[] be a scratch area large enough for the longest
  pathname generated:  a conservative size for buffer[] is
       strlen (name) + strlen (path) + 2
  Does not return on success.

  Example:
       const char *path = getenv ("PATH");
       char *buffer;
       int pid;
       if (path == 0) {
               path = "/bin:/usr/bin";
       }
       buffer = malloc (strlen (path) + strlen (name) + 2);

       pid = fork ();
       if (pid == 0) {
               exec_first_on_path (name, path, buffer, argv);
               perror (name);
               _exit (2);
       }
       ...
 */
void exec_first_on_path (const char *name, const char *path, char
*buffer, char *argv[]) {
       if (strchr (name, '/') != 0) {
               path = "";
       }
       path--;                 /* pretend path has a leading colon
that's never touched */
       do {
               char *p;
               path++;         /* skip colon */
               for (p = buffer; *path != 0 && *path != ':'; *p++ = *path++) {
               }
               if (p != buffer) {
                       *p++ = '/';
               }
               strcpy (p, name);
               execv (buffer, argv);
       } while (*path == ':');
}

In the implementation the 3 macros are somehow used interchangeably.  We
should review each use of them and pick the right one:

GTEST_OS_WINODWS for the Windows OS.
_WIN32 for the WIN32 API.
_MSC_VER for the MSVC compiler.

It should be gtest_main.lib instead of gtest.lib.

What steps will reproduce the problem?
1. ./configure
2. make
3. make check


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

When running 'make check', I expect to see a successful build, followed by all 
tests passing.  
Instead, I see this:
make  samples/sample1_unittest samples/sample2_unittest 
samples/sample3_unittest 
samples/sample4_unittest samples/sample5_unittest samples/sample6_unittest 
test/gtest_unittest test/gtest-death-test_test test/gtest-filepath_test 
test/gtest-message_test 
test/gtest-options_test test/gtest_pred_impl_unittest 
test/gtest_environment_test 
test/gtest_no_test_unittest test/gtest_main_unittest test/gtest_prod_test 
test/gtest_repeat_test 
test/gtest_stress_test test/gtest-typed-test_test  
make[1]: Entering directory `/home/pberry/gtest/gtest-1.1.0'
depbase=`echo samples/sample1_unittest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
if g++ -DHAVE_CONFIG_H -I. -I. -I./config_aux  -I. -I./include   -g -O2 -MT 
samples/sample1_unittest.o -MD -MP -MF "$depbase.Tpo" -c -o 
samples/sample1_unittest.o 
samples/sample1_unittest.cc; \
then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi
/bin/sh ./libtool --tag=CXX --mode=link g++  -g -O2   -o 
samples/sample1_unittest  
samples/sample1_unittest.o lib/libgtest_main.la samples/libsamples.la 
g++ -g -O2 -o samples/.libs/sample1_unittest samples/sample1_unittest.o  
lib/.libs/libgtest_main.so samples/.libs/libsamples.a -Wl,--rpath 
-Wl,/usr/local/lib
samples/sample1_unittest.o(.text+0x1303): In function `global constructors 
keyed to 
_ZN27FactorialTest_Negative_Test10test_info_E':
./include/gtest/internal/gtest-internal.h:484: undefined reference to 
`testing::internal::MakeAndRegisterTestInfo(char const*, char const*, char 
const*, char const*, 
void*, void (*)(), void (*)(), testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x134d):./include/gtest/internal/gtest-internal
.h:484: 
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, 
char const*, 
char const*, char const*, void*, void (*)(), void (*)(), 
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x1397):./include/gtest/internal/gtest-internal
.h:484: 
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, 
char const*, 
char const*, char const*, void*, void (*)(), void (*)(), 
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x13e1):./include/gtest/internal/gtest-internal
.h:484: 
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, 
char const*, 
char const*, char const*, void*, void (*)(), void (*)(), 
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x142b):./include/gtest/internal/gtest-internal
.h:484: 
undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, 
char const*, 
char const*, char const*, void*, void (*)(), void (*)(), 
testing::internal::TestFactoryBase*)'
samples/sample1_unittest.o(.text+0x1475):./include/gtest/internal/gtest-internal
.h:484: more 
undefined references to `testing::internal::MakeAndRegisterTestInfo(char 
const*, char const*, 
char const*, char const*, void*, void (*)(), void (*)(), 
testing::internal::TestFactoryBase*)' follow
collect2: ld returned 1 exit status
make[1]: *** [samples/sample1_unittest] Error 1
make[1]: Leaving directory `/home/pberry/gtest/gtest-1.1.0'
make: *** [check-am] Error 2


What version of the product are you using? On what operating system?

I am using version 1.1.0 on an AMD Opteron 285.  The OS is RedHat 4 update 1.  
Here is the 
result of 'uname -a':
Linux sim12 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42 EST 2007 x86_64 
x86_64 x86_64 
GNU/Linux

And here is the result of gcc --version:
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Please provide any additional information below.

What steps will reproduce the problem?

Follow steps from README files:
  $ ${SRCDIR}/configure  # Standard GNU configure script, --help for more info
  $ make  # Standard makefile following GNU conventions
  $ make check  # Builds and runs all tests - all should pass


What is the expected output? What do you see instead?
Expected output: Builds and runs all tests - all should pass
What I got was:

'make check' fails with following messages:

=====================

FAIL: Tests using the GTEST_BREAK_ON_FAILURE environment variable.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test/gtest_break_on_failure_unittest.py", line 148, in testEnvVar
    expect_seg_fault=1)
  File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
    self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE=1, an assertion failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_" should
cause a seg-fault.

======================================================================
FAIL: Tests using the --gtest_break_on_failure flag.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test/gtest_break_on_failure_unittest.py", line 158, in testFlag
    expect_seg_fault=1)
  File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
    self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE is not set, an assertion
failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_
--gtest_break_on_failure" should cause a seg-fault.

======================================================================
FAIL: Tests that the flag overrides the environment variable.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test/gtest_break_on_failure_unittest.py", line 168, in
testFlagOverridesEnvVar
    expect_seg_fault=1)
  File "./test/gtest_break_on_failure_unittest.py", line 131, in RunAndVerify
    self.assert_(has_seg_fault == expect_seg_fault, msg)
AssertionError: when GTEST_BREAK_ON_FAILURE=0, an assertion failure in
"/home/toni/work/gtest-1.0.0/test/gtest_break_on_failure_unittest_
--gtest_break_on_failure" should cause a seg-fault.

----------------------------------------------------------------------
Ran 4 tests in 0.178s

FAILED (failures=3)
FAIL: test/gtest_break_on_failure_unittest.py
 ...
3 of 26 tests failed
Please report to [email protected]
=====================================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/home/toni/work/gtest-1.0.0'
make: *** [check-am] Error 2



What version of the product are you using? On what operating system?
My environment is Linux: Ubuntu 8.04:
uname -m = i686
uname -r = 2.6.24-16-server
uname -s = Linux
uname -v = #1 SMP Thu Apr 10 13:58:00 UTC 2008

python -V: Python 2.5.2

> gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)


Please provide any additional information below.

RunAndVerify function is mention several times but most probably problem is
in this short function from file "gtest_break_on_failure_unittest.py":

def Run(command):
  """Runs a command; returns 1 if it has a segmentation fault, or 0 otherwise.
  """

  return os.system(command) == signal.SIGSEGV


Statement:
  return os.system(command) == signal.SIGSEGV

never comes "true" because (if you want to test for SIGSEGV):
- signal.SIGSEGV has value 11
- os.system(command) returns 35584 in case that command was killed by
signal SIGSEGV.

Correct check would be (at least in my environment):
  ret = os.system(command)
  return (ret>>8) == (signal.SIGSEGV + 128)

Why this work is explained in man pages for system() and wait() in Python
and C:
=====================
system(     command)
    Execute the command (a string) in a subshell. This is implemented by
calling the Standard C function system(), and has the same limitations.
Changes to posix.environ, sys.stdin, etc. are not reflected in the
environment of the executed command.

    On Unix, the return value is the exit status of the process encoded in
the format specified for wait(). Note that POSIX does not specify the
meaning of the return value of the C system() function, so the return value
of the Python function is system-dependent.

wait(   )
    Wait for completion of a child process, and return a tuple containing
its pid and exit status indication: a 16-bit number, whose low byte is the
signal number that killed the process, and whose high byte is the exit
status (if the signal number is zero); the high bit of the low byte is set
if a core file was produced. Availability: Macintosh, Unix.
=====================

Similar result could be get if you start this sequence of command in bash:
=====================
> sleep 30 &
[1] 28937
> pid=$!
> echo $pid
28937
> kill -segv $pid
[1]+  Segmentation fault      sleep 30
> wait $pid
> echo $?
139
=====================

What steps will reproduce the problem?
1. Create a test which where the expression will throw an exception:
bool ThrowAnException()
{
  throw 0;
}
TEST(Test, Exception) 
{ 
  EXPECT_TRUE(ThrowAnException());
}
2. Run the test
3. Check the result

What is the expected output? What do you see instead?
Expected output should be something like this:
[ RUN      ] Test.Exception 
test.cc:113: Failure 
Unhandled exception caught in: ThrowAnException() 
[  FAILED  ] Test.Exception 

But the current result is:
[ RUN      ] Test.Exception 
unknown file: Failure 
Exception thrown with code 0xe06d7363 in the test body. 
[  FAILED  ] Test.Exception

What version of the product are you using? On what operating system?
1.0.1 on Windows

Please provide any additional information below.
The "unknown file: Failure" message is not so handy. At least the source 
file and line should be reported.

What steps will reproduce the problem?
1. write a test that throws an exception
2. build and run the test on mac and other platforms (mingw/cygwin on windows)
3. exception crashes the test app so no other tests are run or reported

What is the expected output? 
  [ RUN      ] ExceptionsAsErrors.TestThrowsInt
../test/test_exceptions.cc:12: Failure. Exception of type 'int' 
thrown by test.
              (Ideally, print name of exception type, 
               the "what()" string if it is a 
               subclass of std::exception, and a stack crawl.)
  [   FAILED ]  ExceptionsAsErrors.TestThrowsInt

What do you see instead?
  [ RUN      ] ExceptionsAsErrors.TestThrowsInt
  terminate called after throwing an instance of 'int'
  make[1]: *** [run-tests] Abort trap
  make: *** [all] Error 2


Please use labels and text to provide additional information.

this is release 1.1 of gTest

Instead of hardcoding the name as gtest.lib. This reduces errors and
minimizes changes in case we rename a project.

Per Abrahamsen reported that he was able to compile and install Google Test
successfully on Cygwin for MinGW.  "make check" fails with some errors
though.  The following patch by Per fixes some, but not all, errors.

--- gtest-filepath_test.cc_ORIG 2008-09-18 14:16:58.000000000 +0200
+++ gtest-filepath_test.cc  2008-09-30 21:06:27.575000000 +0200
@@ -61,6 +61,11 @@
 #define PATH_SEP "/"
 #endif  // GTEST_OS_WINDOWS

+#ifdef __MINGW32__
+extern "C" int chdir (const char* dir);
+extern "C" int rmdir (const char* path);
+#endif
+
 namespace testing {
 namespace internal {
 namespace {
--- gtest_unittest.cc_ORIG  2008-09-18 14:16:58.000000000 +0200
+++ gtest_unittest.cc   2008-09-30 21:01:37.864000000 +0200
@@ -1030,6 +1030,8 @@
   return;
 #elif defined(GTEST_OS_WINDOWS)  // If we are on Windows proper.
   _putenv((Message() << name << "=" << value).GetString().c_str());
+#elif defined (__MINGW32__)
+  putenv((Message() << name << "=" << value).GetString().c_str());
 #else
   if (*value == '\0') {
     unsetenv(name);