char_traits<unsigned char> will be removed from LLVM 19

[jeffpc]

Building latest galmon master on FreeBSD 14.2 (it uses clang as the compiler) generates a number of warnings which look like:

$ gmake ubxtool
...
c++ -std=gnu++17 -Wall -O3 -ggdb -MMD -MP -fno-omit-frame-pointer -Iext/CLI11 -Iext/powerblog/ext/simplesocket -Iext/powerblog/ext/ -I/usr/local/opt/openssl/include/ -Iext/sgp4/libsgp4/ -I/usr/local/include   -c -o ubx.o ubx.cc
In file included from ubx.cc:1:
In file included from /usr/include/c++/v1/iostream:43:
In file included from /usr/include/c++/v1/ios:223:
In file included from /usr/include/c++/v1/__locale:23:
In file included from /usr/include/c++/v1/string:625:
In file included from /usr/include/c++/v1/string_view:213:
/usr/include/c++/v1/__fwd/string_view.h:22:41: warning: 'char_traits<unsigned char>' is deprecated: char_traits<T> for T not equal to char, wchar_t, char8_t, char16_t or char32_t is non-standard and is provided for a temporary period. It will be removed in LLVM 19, so please migrate off of it. [-Wdeprecated-declarations]
   22 | template <class _CharT, class _Traits = char_traits<_CharT> >
      |                                         ^
./ubx.hh:6:66: note: in instantiation of default argument for 'basic_string_view<uint8_t>' required here
    6 | uint16_t calcUbxChecksum(uint8_t ubxClass, uint8_t ubxType, std::basic_string_view<uint8_t> str);
      |                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__string/char_traits.h:81:8: note: 'char_traits<unsigned char>' has been explicitly marked deprecated here
   81 | struct _LIBCPP_DEPRECATED_(
      |        ^
/usr/include/c++/v1/__config:978:53: note: expanded from macro '_LIBCPP_DEPRECATED_'
  978 | #      define _LIBCPP_DEPRECATED_(m) __attribute__((__deprecated__(m)))
      |                                                     ^

It looks like the warnings are for (but there may be others in parts I don't build - I only care about ubxtool):

• char_traits<unsigned char>
• char_traits<fmt::detail::char8_type>

Presumably, this means that galmon will fail to build with LLVM/clang 19.

[berthubert]

From a cursory glance this is likely an internal C++ library problem. I find no sign that basic_string_view<uint8_t> is deprecated. But I could be wrong, so let's see.

[jeffpc]

FWIW, FreeBSD 14.3 ships with clang 19 and galmon no longer builds since the above warnings are now errors. As far as I can tell, libcxx removed it on purpose:

The base template for std::char_traits has been removed in LLVM 19. If you are using std::char_traits with types other than char, wchar_t, char8_t, char16_t, char32_t or a custom character type for which you specialized std::char_traits, your code will stop working. The Standard does not mandate that a base template is provided, and such a base template is bound to be incorrect for some types, which could currently cause unexpected behavior while going undetected.

https://releases.llvm.org/19.1.0/projects/libcxx/docs/ReleaseNotes.html

[jeffpc]

Based on the comment found on a bug report [1], hitting this error usually occurs when basic_string is used instead of a vector or when developers use stdint types to represent utf16/32 chars. In galmon's case, it looks like basic_string is being used for ubx payload (and maybe other) processing instead of the more appropriate vector - it is binary data, after all.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282329#c1

[omoerbeek]

OpenBSD hits this since the move to clang++ 19.

basic_string says: The definitions of the operations are supplied via the Traits template parameter - a specialization of [std::char_traits](https://en.cppreference.com/w/cpp/string/char_traits.html) or a compatible traits class.

char_traits says:

The standard library provides the following standard specializations:

Defined in header <string>
--
std::char_traits<char> | the standard character traits of char
std::char_traits<wchar_t> | the standard character traits of wchar_t
std::char_traits<char8_t> (C++20) | the standard character traits of char8_t
std::char_traits<char16_t> (C++11) | the standard character traits of char16_t
std::char_traits<char32_t> (C++11) | the standard character traits of char32_t

Note the absence of std::char_traits<uint8_t> or equivalent. A standard library is not required to provide std::char_traits<uint8_t>, with consequences for std::basic_string<uint8_t>.

So no active deprecation, but no guarantee std::basic_string<uint8_t> is provided either, which basically means you cannot use it in portable code. You could provide the implementation for the Traits parameter yourself, no idea how much work that would be.

[berthubert]

Based on the comment found on a bug report [1], hitting this error usually occurs when basic_string is used instead of a vector or when developers use stdint types to represent utf16/32 chars. In galmon's case, it looks like basic_string is being used for ubx payload (and maybe other) processing instead of the more appropriate vector - it is binary data, after all.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282329#c1

appropriate my ass - no one ever said a string was for ascii text only. std::string also offered much better abilities for processing substrings.

[berthubert]

There is a fixed branch now: https://github.com/berthubert/galmon/tree/string2vec

[omoerbeek]

There is a fixed branch now: https://github.com/berthubert/galmon/tree/string2vec

I built ubxtool on OpenBSD from this branch and it runs fine (previously it would fail). The other programs I do not use.

[jeffpc]

On Mon, Jan 05, 2026 at 08:00:10 -0800, Otto Moerbeek wrote: omoerbeek left a comment (berthubert/galmon#179) > There is a fixed branch now: https://github.com/berthubert/galmon/tree/string2vec I built `ubxtool` on OpenBSD from this branch and it runs fine (previously it would fail). The other programs I do not use.

I tried to do a quick build of ubxtool (I also only use ubxtool) on FreeBSD 14.3, but it failed. At first, something about fmt include header not being found and then what looks like similar sort of string issue in one of the submodules. I'll take a look at it in more detail after work. There's a good chance that PEBKAC.

[jeffpc]

So, on FreeBSD 15, gmake ubxtool compiles fine. I only see a couple of warnings (see below) but those appear to be unrelated to the char_traits<> change and the linker errors that have been around for over a year and a half (#174).

Weirdly, on FreeBSD 14.3, there is also the following issue:

$ gmake ubxtool
...
c++ -std=gnu++17 -Wall -O3 -ggdb -MMD -MP -fno-omit-frame-pointer -Iext/CLI11 -Iext/powerblog/ext/simplesocket -Iext/powerblog/ext/ -I/usr/local/opt/openssl/include/ -Iext/sgp4/libsgp4/ -I/usr/local/include   -c -o ubxtool.o ubxtool.cc
ubxtool.cc:22:10: fatal error: 'fmt/format.h' file not found
   22 | #include "fmt/format.h"
      |          ^~~~~~~~~~~~~~
1 error generated.

I have no idea why it can't find the header on 14.3 - it's the same clang version (llvmorg-19.1.7-0-gcd708029e0b2) and I see the same failure on 14.3 when I build using clang 21.1.2. Since 14.3 is going EOL at the end of June, so I don't really care too much about building on it. (I have only one system left that I haven't upgraded to 15.0 yet.)

The above mentioned FreeBSD 15.0 warnings that appear unrelated:

c++ -std=gnu++17 -Wall -O3 -ggdb -MMD -MP -fno-omit-frame-pointer -Iext/CLI11 -Iext/powerblog/ext/simplesocket -Iext/powerblog/ext/ -I/usr/local/opt/openssl/include/ -Iext/sgp4/libsgp4/ -I/usr/local/include   -c -o ubxtool.o ubxtool.cc
In file included from ubxtool.cc:37:
./nmmsender.hh:56:31: warning: moving a temporary object prevents copy elision [-Wpessimizing-move]
   56 |         d_thread.emplace_back(std::move(std::make_unique<std::thread>(&NMMSender::acceptorThread, this, d.get())));
      |                               ^
./nmmsender.hh:56:31: note: remove std::move call here
   56 |         d_thread.emplace_back(std::move(std::make_unique<std::thread>(&NMMSender::acceptorThread, this, d.get())));
      |                               ^~~~~~~~~~                                                                        ~
./nmmsender.hh:59:31: warning: moving a temporary object prevents copy elision [-Wpessimizing-move]
   59 |         d_thread.emplace_back(std::move(std::make_unique<std::thread>(&NMMSender::sendTCPThread, this, d.get())));
      |                               ^
./nmmsender.hh:59:31: note: remove std::move call here
   59 |         d_thread.emplace_back(std::move(std::make_unique<std::thread>(&NMMSender::sendTCPThread, this, d.get())));
      |                               ^~~~~~~~~~                                                                       ~
ubxtool.cc:204:22: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
  204 |       uint8_t buffer[len+2];
      |                      ^~~~~
ubxtool.cc:204:22: note: read of non-const variable 'len' is not allowed in a constant expression
ubxtool.cc:202:16: note: declared here
  202 |       uint16_t len = b[2] + 256*b[3];
      |                ^
3 warnings generated.

and

c++ -std=gnu++17 -Wall -O3 -ggdb -MMD -MP -fno-omit-frame-pointer -Iext/CLI11 -Iext/powerblog/ext/simplesocket -Iext/powerblog/ext/ -I/usr/local/opt/openssl/include/ -Iext/sgp4/libsgp4/ -I/usr/local/include   -c -o zstdwrap.o zstdwrap.cc
zstdwrap.cc:182:7: warning: unused variable 'rc' [-Wunused-variable]
  182 |   int rc = close(d_readpipe);
      |       ^~
1 warning generated.

[jeffpc]

That is, at least as far as building the code is concerned, I think you can merge the branch to master. (NB: I didn't actually look at the code change itself, so don't consider this a code review ;) )

[omoerbeek]

I saw the same warnings on OpenBSD, but thought not to muddy the water with unrelated changes, as the diff is already big enough.

[jeffpc]

On Tue, Jan 06, 2026 at 11:39:01 -0800, Otto Moerbeek wrote: omoerbeek left a comment (berthubert/galmon#179) I saw the same warnings on OpenBSD, but thought not to muddy the water with unrelated changes, as the diff is already big enough.

Absolutely. Those warnings are unfortunate but unrelated and therefore should not be part of the commit for this issue.