Any #GCC folks know why the transparent_union attribute works in C but not C++? The motivating use case is for a system header, which exposes an API that needs to be callable from both C and C++ with identical code, yet it appears that this attribute has never worked in g++ (and is documented as C only). But I can't find any rationale for this choice.

Episode 15 of Dark Blue Weekly released

https://darkblueproject.com/sites/news/dbw-e15.php

#darkblueproject #darkblueweekly #fedora #bazziteos #cachyos #proxmox #gcc #archlinux #linux #linuxdesktop #opensource #freesoftware

@jperkin

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

@jperkin

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

@jperkin

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<typename _T> inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast<double>(__v)); }

inside namespace std, and

#include <iso/type_traits.h>

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

@jperkin

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 <math.h> and <stdio.h> 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 <cmath> functions.

#CPlusPlus #gcc #clang

@jperkin

I'm not sure that this is the best fix.

Since C++2011, there's been a template for std::log in <cmath> 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 <math.h> 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

@davefischer

I'm guessing that that was Ritter's Heirloom vi.

https://mastodonapp.uk/@JdeBP/116052015020764901

There are discussions in an Arch Linux forum of its package being removed because it hadn't changed in two decades and the (GNU flavoured) C language had.

It's in the #FreeBSD ports collection; and several people have independently come up with the Makefile patch that gets it to build on Debian Linux.

https://freshports.org/editors/2bsd-vi/

#vi #retrocomputing #ComputerHistory #gcc #ArchLinux

#netbsd boosted

JdeBP » 🌐 2026-02-11 / 2026-02-11
@JdeBP@mastodonapp.uk

On #Illumos, Joy vi is in /usr/src/cmd/vi:

https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi

On #OpenBSD, Bostic #nvi is in /usr/src/usr.bin/vi/vi; #NetBSD having it in /usr/src/external/bsd/nvi; and #FreeBSD in /usr/src/contrib/nvi:

https://cgit.freebsd.org/src/tree/contrib/nvi/

FreeBSD has an nvi2 in ports:

https://freshports.org/editors/nvi2/

OpenBSD has elvis in ports:

https://github.com/openbsd/ports/blob/master/editors/elvis/pkg/DESCR

Ritter's Heirloom vi is on SourceForge:

https://ex-vi.sourceforge.net

STEVIE was posted to comp.sources.unix in 1988:

https://sources.vsta.org/comp.sources.unix/volume15/stevie/

Unfortunately, Sven Guckes's vi Clones WWW site was never completed with some of this, notably lacking Heirloom vi, for example.

https://guckes.net/vi/clones.html

But it does mention oft-overlooked commercial clones such as Watcom's vi, a from-scratch implementation started in 1983 that is also now source-available:

https://github.com/open-watcom/owp4v1copy/tree/master/bld/vi

#vi #retrocomputing #ComputerHistory #STEVIE #elvis #VIM #NeoVIM #Watcom #OpenWatcom

A new #blog post appears!

I built a native GCC 14.2.0 for Mac OS X 10.4 Tiger PowerPC.

https://briancallahan.net/blog/20250329.html

#macos #macosx #tiger #powerpc #power #unix #bsd #freebsd #openbsd #netbsd #dragonflybsd #linux #solaris #illumos #gcc #llvm #clang #compiler #compilers #assembler #linker #toolchain #freesoftware #opensource #gnu