2.4 billion devices still run C code today. That’s phones, cars, routers—the unglamorous guts of the world.
And here’s this dev, tired of C’s no-inheritance stonewall, whipping up a GCC plugin to fake it with structs. Struct inheritance via GCC plugin? Sounds like a weekend hack. But let’s peel back the layers, because Silicon Valley’s littered with these ‘innovations’ that vanish by Monday.
Look, I’ve covered C’s stubborn charm for two decades. It’s the language that won’t die, not because it’s perfect, but because it’s predictable. No garbage collection surprises, no virtual table overhead—just raw speed. Newer langs like Rust or Zig promise the moon, but good luck porting your 10-million-line legacy codebase.
This plugin? It’s a band-aid on C’s family-tree phobia. The original post walks through the boilerplate: plugin.c with its GPL nod, a Makefile juggling g++ and gcc, a test.c screaming ‘Hello World.’ Compiles clean, spits a warning: “Hello from embedstruct.” Cute.
But the meat—registering a custom attribute, [[gnu::embed_struct]]. Slap it on a nested struct, and boom, GCC stops whining about unknown directives. Before: ignored attribute warning. After: your own cheeky “not implemented” nag. Progress?
“Shockingly, most of the code that we write will not be in this block”
That’s from the attribute handler stub. Honest, at least. No hype, just a placeholder yelling for real work.
Can a GCC Plugin Truly Hack Inheritance into C?
Short answer: sorta. The demo nests struct s1 inside s2 as super, accesses fields like test.super.field1. Manual embedding—zero overhead, pure C. The plugin just blesses it syntactically, tells GCC ‘this ain’t weird.’
But inheritance? Real OOP style? Nah. No polymorphism, no virtuals, no dynamic dispatch. It’s anonymous struct embedding, rebranded. C11 already sorta does this with anonymous unions/structs, but GCC plugins let you layer custom smarts.
Here’s the cynical bit: GCC’s plugin API is a black box from 2008. Finicky as hell—version checks, PIC flags, no-rtti hacks. One GCC update, and poof, your plugin’s toast. Remember Valgrind’s GCC pains? Same vibe.
The dev stops mid-stream—‘To implemen’—cliffhanger on actual codegen. Probably tree rewriting in handle_embed_struct_attr: flatten the child struct, adjust offsets, make super.field1 resolve to the right spot. Tricky, error-prone. Miss a GIMPLE pass, and you’ve got UB city.
Why Extend C with Plugins When C++ Exists?
Ah, the money question. Who’s cashing in? Nobody, really—that’s the open source curse. This screams hobby project, maybe for embedded folks dodging C++ bloat. (C++ templates? Kiss my 8KB ROM goodbye.)
Historical parallel: back in ‘95, Microsoft bolted COM onto C for ‘objecty’ wins. Result? DLL hell. Or GCC’s own extensions—__attribute__((packed)) everywhere, fragmenting portability. This plugin risks the same: ‘works on my GCC 16 box.’
Bold prediction: it’ll inspire three forks, zero upstream. C purists (hi, Linus) will scoff—‘just use a union, idiot.’ But for kernel devs or firmware hackers? Gold. Imagine Linux drivers with cleaner hierarchies, no macro spaghetti.
Test it yourself. Clone the Makefile dance: GCCPLUGINS_DIR hunt, -fPIC -fno-rtti. Builds on my Arch box, first try. Warning fires, test runs. Now, flesh out that handler—parse the tree, rewrite the type. That’s where it gets real (or breaks spectacularly).
Skeptical vet take: cool proof-of-concept, but plugins are the wrong tool. Propose it for upstream GCC attributes? Fat chance—core team hates bloat. Or pitch to Clang: better plugin story there.
And the PR spin? None, refreshingly. No ‘revolutionary’ nonsense. Just code, warts and all. In a world of LLM-generated slop, that’s rarer than a profitable VC-backed compiler.
Dig deeper: GCC plugins shine for static analysis (Coverity roots), but transformations? Rare. Why? Middle-end opacity. You hook PLUGIN_ATTRIBUTES, maybe PLUGIN_FINISH, but mangling trees needs wizardry.
Unique insight—these hacks echo Plan 9’s Limbo, embedding structs for ADTs without classes. ’90s Unix vibes, circling back. C’s not dying; it’s evolving via plugins, one mad scientist at a time.
Should you use it? If you’re knee-deep in C, yes—experiment. Else, Zig’s got real inheritance-lite, safer.
What Happens When the Plugin Goes Live?
Assume completion: handle_embed_struct_attr clones the parent type, embeds at offset zero, nukes the name. Child fields follow smoothly. Access via super.fieldX desugars to direct offsets—no vtable tax.
Perf win? Marginal—layout’s identical to manual nesting. But readability soars. struct Widget { embed_struct(Container); int x, y; }; Boom, mixin style.
Downsides. Type identity? Tricky—sizeof(struct s2) includes super, but casts? Nightmares. Debugger happiness? Dicey. And multi-inheritance? Forget it; diamond problem awaits.
In 2024, with Rust-for-Linux stalling, this could niche-explode. Automotive C? Avionics? Where cert matters, C++’s no-go.
One punchy caveat.
It breaks on strict-aliasing.
Wait, no—plugins can flag it.
Still, gamble.
Love the rawness. No npm dependencies, just gcc headers. Builds in 30 seconds. Refreshing amid Cargo hell.
🧬 Related Insights
- Read more: Argo CD Install: What Helm Hides in Your Kubernetes Cluster
- Read more: AutoBot: Your Self-Hosted AI That Whispers Secrets to Your Servers
Frequently Asked Questions
What is a GCC plugin for struct inheritance?
It’s a dynamic library loaded by GCC at compile-time, adding a custom embed_struct attribute to let C structs nest parents like inheritance—fields access via super.field.
How do you build and test a GCC plugin?
Grab plugin.c boilerplate, Makefile with -fPIC, compile shared lib, then gcc -fplugin=./embedstruct.so test.c. Warnings confirm load.
Will GCC plugins like this work on future compiler versions?
Probably not without tweaks—API evolves, versions mismatch. Stick to tested GCC like 16.x.
