Guten Tag Nathaniel W. Turner, am Donnerstag, 21. Februar 2019 um 17:02 schrieben Sie:
> Wait, isn't the compiler trying to remind us that 0x80 does not actually > fit in a char? (It doesn't.) From my understanding, a "char" holds 8 bits of data and 0x80 only consumes at most that 8 bits in the contexts log4cxx cared about in the past, so the value does fit. What the compiler is telling me is that I won't necessarily get the decimal 128 back, but as this is used as some UTF-8 byte, I don't think we care much. > Wouldn't the correct fix actually be to define > log4cxx::logchar as unsigned char, instead of char? While it might be the formal correct approach, it doesn't seem to be worth it: Using std::basic_string<char> to store UTF-8 seems to be OK currently for most of the world and if that is changed to "unsigned char", a lot of things internally in log4cxx break. Not only regarding strings, but bytes as well, because those worlds are not as clearly seperated as one would expect currently. Additionally, one would get a lot of incompatibility using interfaces like those of APR, which are "char*" currently most of the time as well. I spent some hours yesterday to test this and ended up in a lot of additional CASTs or one might even need to really convert data from "char" to "unsigned char" for formal reasons, where things were simply forwarded as is before. So, I've documented my findings and won't change to "unsigned" for now. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
