Fix sprintf issues

[billsacks]

Fixes uses of sprintf where the output string is also used in the input, which can result in garbled time strings.

Also changes these sprintf calls to snprintf to avoid possible buffer overflows, and checks these calls to ensure that the output variable is large enough to hold the relevant string, returning an error code if not.

Resolves #284

[billsacks]

@oehmke - I'd be happy for a review of this if you'd like to look it over - but I feel good enough about these changes that I don't think a review is necessary if you don't have the time.

[billsacks]

Note that this change is untested because it is inside an #if 0 block.

I tested it by:

(1) Testing the build when I changed #if 0 to #if 1 in the surrounding block

(2) Writing the following test program that checks the msg string before and after this change, ensuring that the resulting string is identical before and after:

#include <iostream>
#include <sstream>

using namespace std;

int main() {
   int num_p = 4;
   double *cd_sph = new double[num_p * 2];
   for (int npt = 0; npt < num_p * 2; npt++) {
      cd_sph[npt] = 24 + 36.003*npt;
   }

   char msg[1024];
   sprintf(msg, " - there was a problem (e.g. repeated points, clockwise poly, etc.) with the triangulation of the element:\n");
   sprintf(msg, "%selem Id: %d clip_elem Id: %d\n", msg, 1005, 123456);
   for (int npt = 0; npt < num_p * 2; npt++)
      sprintf(msg, "%s %g", msg, cd_sph[npt]);

   std::stringstream msg2;
   msg2 << " - there was a problem (e.g. repeated points, clockwise poly, etc.) with the triangulation of the element:\n";
   msg2 << "elem Id: " << 1005 << " clip_elem Id: " << 123456 << "\n";
   for (int npt = 0; npt < num_p * 2; npt++)
      msg2 << " " << cd_sph[npt];

   cout << msg << "\n";
   cout << msg2.str() << "\n";
}

[billsacks]

It looks like the test failure here is just in the ESMF_CompTunnelUTest, which I think @danrosen25 has seen failing in these automated runs periodically.

[danrosen25]

It looks like the test failure here is just in the ESMF_CompTunnelUTest, which I think @danrosen25 has seen failing in these automated runs periodically.

I checked and it's the same error about Finalize finishing in less than 3 seconds even though there's a 3 second delay. The issue for it is here: #295

[danrosen25]

@billsacks
I reran the failed mac os + openmpi test after rolling back the openmpi version. This time it passed. It could be a bug in openmpi or it could just be that openmpi v5+ calls to MPI_Wtime execute faster.

[oehmke]

Looks great! I appreciate your careful testing, especially of the edge cases. It's nice to get this in. It'll make the library safer. Thanks!