Locale-dependent serialization of integer types produces invalid XML

[cgri]

Affected version: XSD 4.2.0 (C++/Tree mapping)
Affected files: xsd/cxx/tree/serialization/int.hxx
(and likely the analogous headers for long, short,
byte, unsigned-int, unsigned-long, integer, etc.)

Summary

The serialization operators for built-in integer types use a
std::basic_ostringstream without calling imbue(std::locale::classic()).
As a result, when the global C++ locale uses digit grouping (e.g. de_DE,
where 42000 is formatted as "42.000"), the generated XML contains
group-separator characters in numeric fields. This violates the
XML Schema specification, which requires xs:int, xs:long, xs:integer
etc. to be serialized as a plain digit sequence with no grouping.

Reproduction

Minimal schema:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="value" type="xs:int"/>
</xs:schema>

Minimal program:

#include <iostream>
#include <locale>
#include <sstream>
#include "schema.hxx"

int main() {
    std::locale::global(std::locale("de_DE.UTF-8"));

    value_t v(42000);
    xml_schema::namespace_infomap map;

    std::ostringstream os;
    os.imbue(std::locale::classic()); // does not help
    value_(os, v, map);

    std::cout << os.str() << std::endl;
}

Expected output:
42000

Actual output:
42.000

The imbue() call on the user-supplied stream has no effect because the
serialization functions internally construct their own ostringstream
which inherits the global locale at construction time.

Root cause

In xsd/cxx/tree/serialization/int.hxx, the insertion operators
construct a basic_ostringstream without imbuing the classic locale
before writing the value. Compare with xsd/cxx/tree/serialization/element.hxx,
where the insert() helper does call imbue(std::locale::classic())
correctly. The fix in element.hxx appears to have been intentional;
the integer-type headers seem to have been overlooked.

Suggested fix

Add os.imbue(std::locale::classic()) immediately after constructing
the basic_ostringstream in each of the affected operator<< overloads,
analogous to the existing fix in element.hxx. The same fix should be
applied consistently across all numeric-type serialization headers
(int.hxx, long.hxx, short.hxx, byte.hxx, the unsigned variants, and
integer.hxx / non-negative-integer.hxx etc.).

Workaround context

This is particularly painful for users who ship XSD-generated code as
part of a library or DLL, where modifying the global C++ locale is not
acceptable (it would affect the host application's behaviour). Per-thread
locale tricks (uselocale on POSIX, _configthreadlocale on Windows) do
not reliably propagate to std::basic_ostringstream in all standard
library implementations, so a library-side fix is the only robust
solution.

Environment

• XSD: 4.2.0
• Compiler: msvc 2022
• OS: windows 11

Happy to provide a patch if helpful.

[boris-kolpackov]

Thanks for the report and the detailed information.

I agree the use of iostream for serializing integers is less than ideal. I am however, reluctant to go with the imbue() fix because in my experience locate-related operations in C++ have large performance overhead. On the other hand, it is generally understood that changing the global locate in C++ (or C) programs is not a good idea. Combined, this would mean that most programs will incur this overhead unnecessarily.

In the next release of XSD we are dropping support for C++98/03. I am wondering if we could find a better solution based on that. Some ideas:

• Use C++11 std::snprintf() which is not locale-independent but only depends on the global C locale (I am a bit fuzzy on the interaction between C++ and C locales) though changing global C locale seems to be a well-understood no-no.

• std::to_string() appears to be locale-independent for integers until C++26 (according to cppreference)?

• Use C++17 std::to_chars() if available.

[cgri]

Thanks for your comment. std::format would also be locale-independent. std::to_string is, as far as i know, locale-dependent and therefore not suiteable for xml serialization.

Anyway, the imbue() fix is actually already used in your codebase, but not consequently in all occasions. I have a working patch, but I did not measure any performance changes.

(e. g. in libxsd/xsd/cxx/tree/serialization/double.hxx the imbue() call is already used - but it would also be required for all primitive types such as int etc.)

I could provide a pull request if you are interested.