Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
CMake is aware of the policy's NEW behavior and the AppleClang compiler
id. Set the policy to NEW explicitly to avoid the warning and get the
NEW behavior.
Also teach the RunCMake test infrastructure to build tests with
-DCMAKE_POLICY_DEFAULT_CMP0025=NEW to avoid the policy warning
in test output that must match specific regular expressions.
CMake's test suite includes a dashboard build of KWSys directly out of
the CMake source tree. Upstream KWSys switched to a dedicated dashboard
but CMake's test should still submit to the PublicDashboard project.
Building CMake with g++ 2.9-aix51-020209 on an AIX 5.3 system gives:
cmsys/hashtable.hxx: In function `const long unsigned int *cmsys::get_stl_prime_list ()':
cmsys/hashtable.hxx:399: warning: sorry: semantics of inline function static data
`const long unsigned int _stl_prime_list[31]' are wrong (you'll wind up with multiple copies)
cmsys/hashtable.hxx:399: warning: you can work around this by removing the initializer
Give get_stl_prime_list internal linkage.
Commit "KWSys: Fix SystemTools environment memory handling" (2012-04-26)
added a _WIN32 case inside !KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H to dllimport
the "environ" global. Howver, KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H is true
on every Windows toolchain we support so the case is never reached.
Furthermore, even if it were reached the use of dllimport is incorrect
because the toolchain might not be compiling with a dynamic runtime
library. Remove the unused incorrect line and supporting conditionals.
The hash_fun.hxx header is configured whether FundamentalType is enabled
or not and so cannot depend on it. Run the relevant platform tests
whether or not FundamentalType is on and configure the result directly
into hash_fun. While at it, remove the dependence of SystemInformation
on FundamentalType too since it needs only information that we now
always compute.
The SystemTools::PutEnv function tries to provide the "putenv" API
without leaking memory. However, the kwsysDeletingCharVector singleton
frees memory that may still be referenced by the environment table,
having been placed there by putenv. If any static destruction or
processing by an external tool happens after the singleton is destroyed
and accesses the environment it will read invalid memory.
Replace use of putenv with setenv/unsetenv when available. The latter
manage internal copies of the values passed instead of referencing the
original memory. When setenv/unsetenv are not available use putenv with
a singleton that removes its values from the environment before freeing
their memory. This requires an "unputenv" implementation. On at least
some platforms it must be written in terms of "putenv" because other
APIs are not available and direct modification of the "environ" global
is not safe (e.g. on Windows there is interaction with "wenviron").
Fortunately either putenv("A=") or putenv("A") will remove "A" from the
environment on these platforms. On other platforms fall back to direct
manipulation of "environ".
Also add UnPutEnv to the API and add a test for the behavior of both.
Brad King
Stephen Kelly
Daniel R. Gomez
David Cole