Pantheios 1.0.1 beta 210 released: closing a vulnerability to badly written third-party libraries

The latest release of Pantheios - version 1.0.1 beta 210 - closes a vulnerability to implicit conversion of instances of fundamental types in the presence of badly-written third-party C++ libraries.

For reasons of robustness, Pantheios log statements do not accept instances of fundamental types - integers, floating-points, bool, char, and so on. Instead, users are advised to select from the set of stock inserter classes and functions provided with the library, or to define their own.

Consequently, and by design, statements such as the following will result in compilation errors:

  #include <pantheios/pantheios.hpp>

  pantheios::log_NOTICE("int: ", 10);

  pantheios::log_INFORMATIONAL("float: ", 1.23);

  pantheios::log_INFORMATIONAL("bool: ", true);

Instead, inserters should be used:

  #include <pantheios/pantheios.hpp>
  #include <pantheios/inserters/integer.hpp>
  #include <pantheios/inserters/real.hpp>
  #include <pantheios/inserters/boolean.hpp>

  pantheios::log_NOTICE("int: ", pantheios::integer(10));

  pantheios::log_INFORMATIONAL("float: ", pantheios::real(1.23));

  pantheios::log_INFORMATIONAL("bool: ", pantheios::boolean(true));

This can be expressed more succinctly by using namespace and inserter aliases:

  #include <pantheios/pan.hpp>
  #include <pantheios/inserters/i.hpp>
  #include <pantheios/inserters/real.hpp>
  #include <pantheios/inserters/b.hpp>

  pan::log_NOTICE("int: ", pan::i(10));

  pan::log_INFORMATIONAL("float: ", pan::real(1.23));

  pan::log_INFORMATIONAL("bool: ", pan::b(true));

Unfortunately, in the presence of ATL or MFC - or any other library that has conversion constructors and for which string access shims are defined - the former statements will compile and execute, but will not produce the expected output. Consider the following code:

#include <afx.h>
#include <pantheios/pan.hpp>

  pan::log_NOTICE("int: ", 10);

In a wide-string build in the presence of MFC, then rather than causing a compilation error, the 10 will actually be converted to an instance of CString, via the conversion constructor taking a TCHAR argument!

Obviously this is not desirable, particularly not for a diagnotic logging library! As of 1.0.1 beta 210, there are compile-time constraints in the application layer function templates - log(), log_DEBUG(), etc. - that cause a compile error if any argument is of fundamental type.

Wide String Shims for std::exception

The new release of STLSoft supports seamless use of exceptions with Pantheios (and FastFormat)  in wide-string builds; described on this post on the STLSoft project blog.

b 196 imminent: full wide-string support

Title pretty much says it all. Am swamped - what's new - with commercial activities, but am hoping to get this out over the coming weekend.

Pantheios 1.0.1 beta 195 released: enhanced pantheios::w2m inserter

The latest release of Pantheios provides enhanced flexibility for the pantheios::w2m inserter class. As well as passing wide C-strings, as in:

  void f(wchar_t const* s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

the new facilities allow passing wide string class instances, as in:

  void f(std::string const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

and

  void f(stlsoft::simple_wstring const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

Previously, the log statement would have to explicitly elicit the C-string pointer and the length, as in:

  void f(stlsoft::simple_wstring const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s.data(), s.length()), ")");

    . . .

  }

Obviously, this is far less expressive than the new facilities.