Bogus test for strerror_r in GenerateDCMTKConfigure.cmake

[chaircrusher]

This CMake code makes no sense, and at least on OS X with GCC or CLANG:

The problem? This DCMTK_TRY_COMPILE succeeds when strerror_r returns an int, but then it sets HAVE_CHARP_STRERROR_R which should be FALSE. And the comment "strerror_r returns an int" is the opposite of what the symbol name HAVE_CHARP_STRERROR_R indicates.

The consequences later is that when strerror_r is actually called, it is a compile error.

Why has no one else besides me run into this?

And while I'm complaining, the comment about there only being a warning when strerror_r returns int is nonsense.

# Check if strerror_r returns a char* is defined.
DCMTK_TRY_COMPILE(HAVE_CHARP_STRERROR_R "strerror_r returns an int"
"#include <string.h>

int main()
{
// We can't test \"char *p = strerror_r()\" because that only causes a
// compiler warning when strerror_r returns an integer.
char *buf = 0;
int i = strerror_r(0, buf, 100);
return i;
}")

[J. Riesmeier]

Thank you for the report. I guess you are referring to the 3.6.0 version of DCMTK, right? We will check the behavior on Mac OS X (as soon as we find an appropriate test system).

And while I'm complaining, the comment about there only being a warning when strerror_r returns int is nonsense.

No, OS X is not the center of the world On other systems, the comment is definitely true (as the author of this CMake test confirmed).

[chaircrusher]

Thank you for the report. I guess you are referring to the 3.6.0 version of DCMTK, right? We will check the behavior on Mac OS X (as soon as we find an appropriate test system).

Well I can run tests.

And while I'm complaining, the comment about there only being a warning when strerror_r returns int is nonsense.

No, OS X is not the center of the world On other systems, the comment is definitely true (as the author of this CMake test confirmed).[/quote]

Every compiler to which I have access to on both Linux and OS X thinks this is an error:

int x() { return 1; }

int main(int argc, char **argv)
{
char *c = x();
return 0;
}

[J. Riesmeier]

I just noticed: The issue with the strerror_r() test has already been reported to us last November. The affected system was Mac OS X Lion with XCode 4.2.

Did you also test or could you please also test whether the configuration process works with GNU autoconf (i.e. configure)? Please use the latest DCMTK snapshot from December 2011.

[Uli Schlachter]

Sorry my fault (and I even managed to convince Jörg that there was no fault at all).

This CMake test is a port of the same autoconf test. However, since this test fails if it succeeds, I got some things mixed up. At first it worked correctly, but then I later broke it when I cleaned something up.

For why "only you" see this issue: If strerror_r() really returns a char*, but HAVE_CHARP_STRERROR_R isn't defined, the result from strerror_r() is cast to (void) and discarded. Thus the compiler didn't catch the problem.

Could you verify if this commit fixes the problem for you too?
http://git.dcmtk.org/web?p=dcmtk.git;a= ... 2a74542f37