Safely abstracting use of strerror / strerror_s (part 1)

A recent bug report on the STLSoft SourceForge project site reported that the stlsoft::error_desc component did not use the new "safe string" library function strerror_s(). This was actually a surprise, because I thought I'd already taken care of that.

Since I hadn't, I decided that I should. The change in implementation to use strerror_s() (when in the presence of the "safe string" library) goes along the lines of the following

char buff[1001];
if(0 != ::strerror_s(buff, 
            STLSOFT_NUM_ELEMENTS(buff) - 1, errno))
{
  buff[0] = '\0';
}
else
{
  buff[STLSOFT_NUM_ELEMENTS(buff) - 1] = '\0';
}

The dumb part of the strerror_s() function is that it doesn't tell you how many characters were received. This means that you cannot rely on having elicited the full message unless ::strlen() over the returned string is less than (buffer size - 1). So, the above code could return a partial error string (although the likelihood of that is, of course, vanishingly small).

Instead, what I've done is used an auto_buffer to provide resizable storage, and then strerror_s() is called in a loop until either it fails, or no more storage can be allocated, or the length of the returned string is less than (buffer size - 1). The code looks like the following:

stlsoft::auto_buffer buff(128);

for(;;)
{
  int n = ::strerror_s(&buff[0], buff.size() - 1, error);

  buff[buff.size() - 1u] = '\0';

  if(0 == n)
  {
    size_t cch = ::strlen(buff.data());

    if(cch < buff.size() - 2u)
    {
      m_length = cch;
      buff.resize(cch + 1u);
      break;
    }
  }

  if(!buff.resize(1u + buff.size() * 2u))
  {
    buff.resize(1u);
    break;
  }
}

There's another problem with the class template, but that'll have to wait until a later time to discuss ...

STLSoft site moved to SourceForge

As part of the movement of STLSoft over to SourceForge, I've just put in the DNS changes. Expect a few hiccups in the next few hours, as the DNS record updates are rolled out, after which the new site should be available.

Please visit the site, http://stlsoft.org/, and provide feedback on the services/content provided there.

Also, please feel free to make use of the forums and the trackers. These will be preferred over this newsgroup, or direct emails, from this point onwards for keeping track of bugs, feature requests, tutorial questions, and so forth.

Matt

STLSoft moving to SourceForge

I've finally got myself together, and am moving STLSoft from the Synesis Software site to SourceForge.

Over the coming months you can expect to see the following changes:

• The distributions available solely from SF
  
• The stlsoft.org domain will be hosted on SF
• A wiki will be configured and built up
• Subversion repository (but not before 1.10 is released, and a whole lot of TODOs are TODONE)
• Blogs will be added
• Forums will be added