Replace vsprintf with vsnprintf

[bendudson]

Safe version, which guards against buffer overruns
by specifying the length of the buffer into which text
is being printed.

This was used in both Output and BoutException classes
to provide C printf-style output.

This fixes issue #286

[ZedThree]

Can this be a constant too? BoutException::BUFFERLEN?

[dschwoerer]

The return value of vsnprintf should be checked, and if smaller than the buffer size, a sufficiently large buffer should be allocated - or an exception should be thrown (easier)

[bendudson]

Throwing an exception inside BoutException could end badly. In output I don't think throwing an exception is the best way. These outputs will be mainly used for printing information on a run as it goes, so terminating just because an output couldn't be printed is probably not what the user would want. Possibly allocating more memory, but 1024 characters should be enough for anyone...

One question is how fixes like this should be applied to next. Should there be a second branch from next, which would presumably then conflict in any merge, or wait and merge master into next later?

[dschwoerer]

In output, this would only happen if the path of the file, you are trying to open would be longer than whatever.
In that case, ignoring is terrible, as it might overwrite anything. Maybe something important ...

In exception it shouldn't be to much work to reallocate memory ...

[ZedThree]

With a bit of luck, next will be ready to be merged into master soon-ish. Then, hopefully the development branch and master won't be too far apart, so hotfixes like this can be applied to both at the same time, though that would have to be done from the command line (or with a second PR, I guess?)

[ZedThree]

Good point about output filenames.

Linux has a maximum path length of 4096 characters. Although I'm not sure we want to be allocating that much all the time.

[bendudson]

ok, this is used in three places:

1. In Output as a printf() convenience. This doesn't open any files, and only writes text to stdout and the BOUT.log files. Here allocating memory would be nice, but not essential. Throwing an exception is not desirable.

2. In BoutException to format error messages. I think allocating or reallocating memory here is not advisable, because the exception may have been thrown due to memory corruption and so allocs/frees may cause further exceptions. I think the only option here is to ignore anything not printed.

3. In DataFile, where it is used to create file names. This still uses vsprintf, not vsnprintf. I agree there is a potential issue with this, and either it needs to allocate more memory or throw an exception.

The correct fix in "next" would be to use variadic templates for the functions, rather than C vararg.

[dschwoerer]

About 1):

  int open(const char *fname, ...); ///< Open an output log file                                                                             

seems to me like it would be opening a file, not writing to it.
On the other hand, I am not sure this is often used ...

about Output::write I think an error here could be ignored ... ( I missed earlier that vs(n)printf is used here as well)

about 2):
We are anyway allocating memory for the buffer, and in general a whole exception is constructed.
I am not sure an extra delete/new call would make a difference.

about 3)
This was the main reason I opened this issue :)