[boost] greg_month segfault

From: Stephan Thomas Lavavej (stl_at_[hidden])
Date: 2003-09-13 05:00:21

lexical_casting a greg_month to a string (or an int, or anything) causes
a segfault. Hao Huang has identified the problem, but I don't think it's
been fixed yet.

Boost bug (submitted by Hao Huang):
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=796799&group_id=7586

gcc bug (submitted by me):
http://gcc.gnu.org/PR11838

At the time I submitted the second link, I wasn't sure whether gcc or
Boost was at fault, but after poking through Boost's internals and looking
at the first link, I believe that Boost is at fault. The infinite
recursion identified by Hao Huang causes the segfault that I had noticed
earlier.

(I don't know why MSVC has no problem with this, as someone reported when
I first pointed out the segfault.)

I think the fix would be to replace
      os  << std::setw(2) << std::setfill('0') << m;
with
      os  << std::setw(2) << std::setfill('0') << static_cast<int>(m);

I'm not sure if this is the correct solution, though.  I don't even like
it.

Currently, I lexical_cast<string, int> greg_months, which avoids the
infinite recursion by first effectively static_casting the greg_month to
an int. This has different semantics: it prints the greg_month without
padding, which is what I want. Were lexical_cast<string> of a greg_month
to be fixed so that it worked as intended, it would print out greg_months
with padding all the time, even if the user didn't want or expect it. The
only way to get an unpadded greg_month, which I would consider the
default, would be to use the more verbose lexical_cast<string, int>. Ugh.

I would suggest that lexical_cast<string> of a greg_month both be fixed to
avoid the infinite recursion and changed to not pad the resulting string
with zeroes. After all, lexical_cast<string> of any normal integer doesn't
attach leading zeroes. If the user wants leading zeroes (as an alternative
code path in my program provides), a simple function can easily be
written to provide them.

Thus, the line would be changed to:
      os  << static_cast<int>(m);

My apologies if someone has already noticed the connection between the
two links above and is working to correct the problem. I figured
another ping couldn't hurt.

Stephan T. Lavavej
http://stl.caltech.edu