[RFC] 27_io/ios_manip_basefield.cc

[Paolo Carlini <pcarlini at unitus dot it>]

Hi all, hi Benjamin,

I'm trying to understand more of it.
In fact test02 is ok, test01 is the culprit. Here it is, for your convenience:

////////////////////////////
int
test01()
{
  bool test = true;
  const char lit[] = "-0 123 456\n:-01 234 567:\n:-0 123 456 :"
                     "\n:   -012 345:\n:-    01 234:\n0x000012 345 678";
  std::ostringstream oss;
  oss.imbue(std::locale(std::locale(), new MyNP));
  oss << std::oct << std::showbase;
  oss << -0123456l << std::endl;

  oss << ":" << std::setw(11);
  oss << -01234567l << ":" << std::endl;

  oss << ":" << std::setw(11) << std::left;
  oss << -0123456l << ":" << std::endl;

  oss << ":" << std::setw(11) << std::right;
  oss << -012345l << ":" << std::endl;

  oss << ":" << std::setw(11) << std::internal;
  oss << -01234l << ":" << std::endl;

  oss << std::hex;
  oss << std::setfill('0');
  oss << std::internal;
  oss << std::showbase;
  oss << std::setw(16);
  oss << 0x12345678l << std::endl;

  assert( oss.good() );
  std::cout << oss.str() << std::endl;
  assert( oss.str() == lit );

  return 0;
}
/////////////////////////////

Currently it fails, since the projected output is very different from the actual
output:

037777654322
:037776543211:
:037777654322:
:037777765433:
:037777776544:
0x00000012345678

It looks like there is very little doubt according to the standard that indeed
octals have to be used in the first 5 raws (contra the projected output). Also,
the 6th raw seems to me correctly padded, according to 22.2.2.2.2, table 61. Do
we agree on this?

The only delicate point seems to be that regarding the grouping, which we
currenlty ignore *on purpose* for octs and hexs, locale_facets.tcc line 733:

      ...

      bool __dec = __basefield != ios_base::oct
            && __basefield != ios_base::hex;
      if (__grouping.size() && __dec)
         {
           _CharT* __p;
           __p = __add_grouping(__ws2, __np.thousands_sep(), __grouping.c_str(),

           __grouping.c_str() + __grouping.size(),
           __ws, __ws + __len);
           __len = __p - __ws2;
           // Switch strings.
           __ws = __ws2;
         }
      return _M_insert(__s, __io, __fill, __ws, __len);

      ...

It would be easy to change this behaviour. A few other implementations (STLPort,
Metro, Dinkum) in fact seems to prefer doing the grouping for hexs and octs too.
But Benjamin mentioned the LWG, perhaps there is a defect regarding this? I
could not find one. I'm puzzled since it seems to me that the current standard
does not distinguish dec from hex and oct for grouping (22.2.2.2.2,16).

Either case (grouping or not) we can rather easily, IMO, get rid the failure, by
changing _M_widen_int or the projected output.

Ciao,
Paolo.