Neither GCC nor Clang are compliant with standard C++

https://sebsite.pw/w/20260708-badstdcxx.html

by birdculture • 3 days ago

49 58 3 days ago

sebsite.pw

jdw642• 3 days ago

But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn't it been changed?

[1]https://cplusplus.github.io/CWG/issues/1555.html

gregdaniels421• 3 days ago

The working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.

jdw642• 3 days ago

Is it because the impact of the change is too big? I mean, is that why it's hard to submit a proposal?

ndesaulniers• 3 days ago

Shrug, then write a defect report?

froh• 3 days ago

on the standard? or the compilers? or both?

leecommamichael4• 3 days ago

If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable.

Context: I am a programmer and educator. I am so tired of informing people of these minutiae.

feverzsj• 3 days ago

Only if you don't code for living.

jjmarr2• 3 days ago

Unfortunately I'm a GPU programmer. C++-based CUDA/HIP is still the standard regardless of how much people would rather use Rust to program GPUs.

tadfisher• 3 days ago

Who is stopping you? Is it an employment concern?

tsimionescu3• 3 days ago

Systems programming is very much about minutiae, to a great extent. And this particular detail will affect any systems language, one way or another. Every language has to decide if the calling convention is part of the function signature or not, and every systems language then has to decide whether it allows C functions with the same name as native functions or not. The C++ standard decided to allow this, which actual C++ compiler implementers decided to ignore for whatever reason, but that's just a bug, of which, again, you'll find many others if you actually do systems programming.

I'll also note that "Odin, Rust, Zig" is a weird enumeration - neither Zig nor Odin are anywhere near being a realistic option for a new complete system. Odin is so obscure it doesn't even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.

jstimpfle• 3 days ago

To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).

leecommamichael4• 3 days ago

I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?

Joker_vD2• 3 days ago

Every language has to decide if the calling convention is part of the function signature or not

Well, of course it is. If you get the calling convention wrong, then you can't actually reliably call the function. I've seen this in e.g. Win32 — pass the function with the wrong calling convention as your callback, and it will dutifully thrash your stack.

The only other option is "pretend that there is only single calling convention that everyone uses" which is apparently somewhat works on platforms that are not 32-bit x86, but only mostly.

The C++ standard decided to allow this,

Decided to prohibit, actually.

which actual C++ compiler implementers decided to ignore for whatever reason,

Because it's UB anyway so why bother detecting it, and it mostly works most of the time when people use it, so again, why bother prohibiting it? No promises on keeping things working in perpetuity, of course.

t0mpr1c38• 3 days ago

Lindy's Law says C will be around longer than any of that lot. Although I wouldn't bet against Rust now that it's used for Linux drivers.

bee_rider2• 3 days ago

C will outlive all of us.

C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?

pjmlp4• 3 days ago

While both C and Rust compiler infrastructure used by Linux drivers is written in C++.

wyattblue• 3 days ago

Consider Nim too!

lallysingh2• 3 days ago

I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.

I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?

What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.

Yes Rust and its libraries are getting better. But so's C++.

leecommamichael4• 3 days ago

These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.

1122333• 3 days ago

On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?

Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.

kloop• 3 days ago

Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++

Standard in the sense of commonly used or supplied

pmkary• 3 days ago

I laughed so hard at this....

pizlonator• 3 days ago

Yes

The only truth is shipping code

Specs are secondary

ksec• 3 days ago

Yes. And Hasn't this always been the case? Before GCC and Clang took over everything there were plenty of C / C++ compilers from Intel, Visual C++ etc.

dataflow2• 3 days ago

The blog post basically said exactly this:

IMO the blame here doesn't lie on gcc or clang; it lies on the standard. that is, the standard is wrong and should be updated to make this implementation-defined.

ch_123• 3 days ago

Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers/runtimes/etc. from different vendors, each of which had incentives to add non standard features to attract customers and keep them locked in. This has been significantly diminished in the last decade or two now that most languages have high quality open source implementations - now you can simply port your compiler of choice to the platform you need.

ameliaquining• 3 days ago

I half-agree with this. People occasionally argue that, e.g., Rust won't be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn't serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and standard library APIs that work everywhere, so that library authors can write portable code that users of any implementation can depend on.

Of course, it's always possible that the standardization body doesn't in practice do a very good job, as seems to maybe be the case with the C++ committee. Also, I'm only talking here about technical considerations, not governance ones.

jamesfinlayson• 3 days ago

On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and standard library APIs that work everywhere

Yeah this was what I thought. I remember Valve Software wrote a paper about cross platform development and said it was useful compiling with Visual C++ and gcc to shake out any iffy syntax that worked in one but not the other. Of course with performance-critical code and code that needs to run on consoles as well there will always be platform-specific stuff, but if you can get 99% of the code working across multiple compilers that's pretty good.

Fudgel• 3 days ago

https://archive.md/lBvFq

dataflow2• 3 days ago

gcc and clang can't change their behavior because that would be a breaking ABI change

It's an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.

Joker_vD2• 3 days ago

Eh, both are about the same? With the source-level API changes, you can patch the source code or, you know, just keep using the already existing binaries, or keep using the old compilers. But if you break ABI, you can't keep using those already existing binaries, you need to start upgrading in bulk. Using the new compilers. That also probably have some source-level API changes. Oh dear.

rurban• 2 days ago

It's about language *linkages*, not about extern "C" vs C++ linkage. It's about stdcall, cdecl, fastcall, vectorcall, watcall, and other calling conventions, which should be in the type. And they are.

Neither GCC nor Clang are compliant with standard C++

Related Stories