Skip to content(if available)orjump to list(if available)

Compiler Bug Causes Compiler Bug: How a 12-Year-Old G++ Bug Took Down Solidity

metadat

What is the appeal / high utility use-case for the spaceship "<=>" operator? It seems quite intuitive to me.. too many doodads is a turn off, like a car with excessive modifications. Does continually adding more then more more more eventually become a stressful nightmare of complexity?

For a concrete example of what this looks like, check out the Homer Simpson -designed car.

https://media.wired.com/photos/593252a1edfced5820d0fa07/mast...

p.s. Fascinating bug! One of the most interesting cases I've encountered.

tialaramex

The spaceship operator is an attempt to achieve the same thing as Rust's PartialOrd -- to have a single authoritative place to explain the ordering of a type.

Historically C++ only had these separate comparison operators, and operator overloading, and so if you want ordering you'd be expected to override all of the operators and do so in a consistent way. Turns out it's easy enough to get that wrong and if you do now your C++ program is often nonsense, it has no defined meaning whatsoever. For example if a < b && b < a then too bad now many built-in library functions might do absolutely anything in say C++ 17.

With the spaceship operator you're still screwed if your type provides an incoherent ordering (unlike Rust where that just means the type is less useful) but it's much more likely you'll write something which actually works.

vlovich123

All I took away from this is how more and more complicated C++ as a language becomes to make the syntax slightly more convenient.

saghm

I get as exasperated at C++ as anyone else, but IMO there's another takeaway here, which is that smart contracts are an absolutely terrible idea. Relying on code as the source of truth for a transaction just completely disregards the reality that code is always going to be buggy. For those who might not be aware, this is the same smart contract framework where someone accidentally killed $300 million of transactions because a function in a library for setting the wallet associated with a private key was defined as public instead of private: https://medium.com/cybermiles/i-accidentally-killed-it-and-e...

Yes, you can fix issues like this with a "hard fork" if you have a large enough consensus, but at that point, does the system of having smart contracts actually improve anything over the one where the software is downstream rather than the source of truth, or are you just replacing one form of "human intervention required" with a different but worse one?

RealityVoid

As opposed to being subject to interpretation of the truth, with the courts of varying quality. My point is... everything has error bars.

usmannk

This is about a language compiler bug. There are no takeaways about smart contracts here.

tsujamin

So long as you’re writing your smart contracts with a chisel, into a stone tablet, with no compilers or assemblers in sight!

saghm

It's about a compiler bug in C++ that had downstream effects in the compiler for Solidity, which is a language for developing smart contracts. Yes, every compiler can have bugs, even ones not relating to smart contracts, but that doesn't seem like a very convincing argument that we should be using compilers for more things rather than boring regular code that isn't considered to be contractual.

charcircuit

You can fix smart contracts without a hard fork. In fact it's common practice for them to be upgradable.

saghm

Does it fix them only going forward, or does it actually update what happened in previous transactions retroactively? If the latter, does everyone involved with any transactions using the said contract have a say in whether the upgrade occurs? I'm skeptical that this would actually be a good mechanism in general given how likely it seems that some contracts might be so widely used to essentially require a hard fork in order to upgrade retroactively, but I'm open to the idea that I might be missing something here.

twoodfin

It’s less about convenient syntax and more about simplifying the construction of abstractions.

You could argue that the latter is the core drive to evolve the standard.

mgaunard

Every new version of C++ (and sometimes even new versions of C++ compilers) can break code in subtle ways.

You should always do extensive testing before upgrading.

vlovich123

I have not observed the same with other languages, whether that’s Java, Rust, or Swift.

And note this is about an older compiler version using an older library with a “newer” language spec (ie been around 5 years). If you use up to date toolchains there’s less of an issue. This is yet another perennial weakness in the c++ ecosystem that isn’t present in other languages because the standard committee continues to abrogate their duties here.

reactordev

That’s the crux of the issue. People fear upgrading because of the bugs introduced by more complexity for more terse syntax.

How much longer will you suffer?

mgaunard

The same is true for any software. If you care about reliability, you pin, and carefully test before upgrading.

immibis

It's not slightly, it's substantially more complicated to become substantially more convenient. The leap from C to C++ is similar to the leap from assembly code to C. As you add features, the language becomes more complex. That's just how it is.

Most languages deal with this by limiting the features they have - but not C++! (or Scala, which is like Java's C++)

vlovich123

I have observed significantly better useful features from Rust or Swift (or Scala) without horribly complicating the language like C++ does. More importantly, they migrate existing codebases and have migration tools instead of breaking old versions of syntax. Rust’s is the most ambitious here letting you mix match editions of the language within a single binary.

bri3d

This is a perfect summary of C++: substantially more complicated for substantial convenience.

Add Boost to the mix, as in this bug, and C++ becomes quite ludicrous really, but it can also combine efficiency, interoperability, and performance in a way that's quite difficult to achieve in other languages.

IMO, starting a good C++ project is an exercise in defining a specific language based on a subset of C++ more than anything else: done right, it can be a big lever, done wrong, it can be a big foot-gun.

tialaramex

If we make the underlying mistake in Rust (actually I did last week for unrelated code) by defining an operator implementation as simply calling itself rather than calling some concrete implementation, the compiler warns us, this is infinite recursion which probably wasn't what you wanted.

G++ has to emit code here to recurse infinitely, so it's not as though there's no opportunity to say "Huh, that probably won't be what they meant"

ranger_danger

You don't have to use all the fancy new features though. Personally I just stick to C++98 for the most part, unless I really want to use auto or lambdas for some reason, then I might use 11, but I won't go higher.

wavemode

Scala has the advantage (and disadvantage) of not caring one lick about backwards compatibility. They were perfectly happy to burn it all to the ground and redo the language's syntax in v3. And even point releases of Scala frequently have breaking changes.

yjftsjthsd-h

Okay, but why

  // SPDX-License-Identifier: UNLICENSED
on 6 lines of trivial example code? Of all the things to make proprietary...

layer8

More importantly, it’s apparently non-conforming: https://opensource.stackexchange.com/a/12412

Other than that, simply not specifying any license would be equivalent.

tczMUFlmoNk

It seems that the Solidity compiler complains if you do not specify one:

https://stackoverflow.com/questions/68332228/spdx-license-id...

dejj

Would the license help to prevent an AI training on the example code?

qualeed

If they eventually start paying attention to licenses, maybe?

LtWorf

No, AI companies are apparently exempted from copyright laws.

edit: bring on the downvotes… doesn't change the fact that fb illegally downloaded a lot of material to train, and so did every other AI company.

typpilol

I saw that too and had to double take lol

nly

Seems like the free comparison function in boost rational should have been constrained to non-rationals

i.e. !is_same_v<rational, U>

questionaaire

My only question is how this operator== override eluded the g++ test suite:

https://osec.io/blog/2025-08-11-compiler-bug-causes-compiler...

jeffbee

All test suites have coverage gaps. The fixing commit adds tests. https://gcc.gnu.org/cgit/gcc/commit/?id=c1e54c82a9e1855499ef...

The better question, in my opinion, is how many other known defects are just sitting there in the GNU buganizer with good reports for more than a decade.

moonlet

I brain-typo’d the title into a 12-year-old girl’s bug taking down Solidity and this, frankly, does not live up to that hype

null

[deleted]