> Tcc still have to be reliable and not falling on simple corner cases because someone decided to push a
> patch on the mob branch, requiring someone else to remove it.
It did not fail, and there is no "requirement" to remove it. That said,
I did update it to remove the unneeded malloc.
> I'd like tcc not to be considered just a "quick hack" or a "toy compiler" due
> to its inherent simplicity, it still have to produce correct and reliable code.
> Especially since its internals are so "simple", there is no reason tcc couldn't
> be thoroughly tested and stabilized orthogonally across all supported architectures.
That does not happen if there are no defined release cycles.
> Let's do a feature freeze first, a comparison checklist with other compilers, supporting
> common flags and attributes, producing correct binary files (Windows, Linux, Mac, ...).
I am working on ARM-PE support, and verification of PE in general (when compared to what
Visual Studio generates.)
> Then after a few release candidates, maybe only we could decide the last RC to be
> worthwhile enough to get released with the new official 0.10.0 tags that we could feel proud of.
Just in time for the holiday season - in 2024 :)
> Our view on tcc may diverge, but rest assured I like it anyway, I just would like it to be treated
> more fairly and professionally than its original legacy.
That usually does not happen without regular updates, a defined release policy, and so on. If
I tell my boss "Hey, lets go and use this compiler!" and he sees its last release was 5 years ago,
he'll tell me to just take a few days off and come back all rested :)
--Fred