Elektrine
Log in Register

#clang

6 posts · Last used 3d

Back to Timeline
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk I'm not sure that this is the best fix. Since C++2011, there's been a template for std::log in that takes an integral type argument and so is the best match without ambiguity. https://cplusplus.com/reference/cmath/log/ vide libstdc++ https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_global/cmath;hb=HEAD#l322 and libc++ https://github.com/llvm/llvm-project/blob/main/libcxx/include/__math/logarithms.h#L35 Illumos's C++ support in isn't up to date with respect to C++ 2011 (unsurprisingly) and a fix that would actually improve and modernize the C++ support seems to be to add these templates for log and whatnot, in some fashion, with appropriate C++ version and type guards, to head/iso/math_iso.h where all of the other C++1998 overloads already are. That would remove ambiguity for both log(1) and std::log(1). #CPlusPlus #Illumos #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk If I had an #Illumos system to do such work on, I probably could. Your patch is breaking the uniform way that the library is designed, over a whole load of headers. In this design, all of the overloads are declared inside namespace std in some iso/*_iso.h header, which headers like and and so forth then pull into the global namespace with using declarations. Ironically, it's a far more full-on C++ way of doing things because it's even declaring the C library functions in namespace std, but with "C" linkage. namespace std gets 1 "C" linkage overload and 2 "C++" linkage overloads for the various functions. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk Retaining that uniform, clean, system involves adding the stuff that's needed for more modern C++ anyway into the right iso/math_iso.h header. If I were doing that, head/iso/math_iso.h would gain something like template inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast(__v)); } inside namespace std, and #include at the top. There'd be an head/iso/type_traits.h with the well-known implementation of enable_if<> as __illumos::__enable_if<> and a suitable implementation of __illumos::__is_integral<> instantiated as appropriate. #CPlusPlus #gcc #clang #Illumos
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk All that said, the big question to answer is whether there is still in use an #Illumos C++ compiler that does not use either GNU libstdc++ or LLVM libc++. (Likely yes if a compiler bootstrap uses C++ before it has its own library built.) Because the inlined "C++" linkage stuff declared by the Illumos library has a fallback to other inline functions if using libstdc++ or libc++, the very easiest patch of all would seem to be just conditionally compile out (only) the extern "C++" {} block of head/iso/math_iso.h when either _LIBCPP_VERSION or __GLIBCXX__ is defined. That way, anything building with libstdc++ or libc++ doesn't get the Illumos "C++" linkage overloads as overloads in the global namespace, and only gets the 1 "C" linkage overload. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk You've missed two important bits. Your initial approach didn't test for _LIBCPP_VERSION or __GLIBCXX__. Your initial approach rather compiled all of this out except for one specific compiler. What I just described, in contrast, compiles everything in for all compilers except when libstdc++ or libc++ are used. It's library-sensitive, not compiler-sensitive. Because there's a stage at least in the GCC bootstrap where it is building itself with the pre-supplied compiler and library. In this mode, one does *not* want the #Illumos headers to have their C++ parts conditionally compiled out. One rather wants them to be fully natively functional the same as they are now. I also said *only* the extern "C++" {} block. Your initial approach went far beyond that and compiled out the declarations of a whole bunch of "C" linkage stuff. #CPlusPlus #gcc #clang
0
0
0
@phantasus@fedi.at · Jan 27, 2026
I'm a senior software developer who is proficient in #ruby #elixir #sql #java #linux #clang #javascript #python #postgresql #postgis #mqtt #rabbitmq I search for a #job and I reside currently in #austria #vienna and I'm fluent in #german and #english I love #foss #opensource and #rest #api Let's #getfedihired #gethired #hiring
13
0
59

You've seen all posts