4 ms·
Reading most thread of llvm bugs so far about there "undefined behaviours" I see a pattern. Llvm goal is performance over correction. stop. If old code breaks
by SFJulie 11y ago
Reading most thread of llvm bugs so far about there "undefined behaviours" I see a pattern.
Llvm goal is performance over correction. stop.
If old code breaks, it is you played with fire, correct your code to eliminate these undefined behaviours. Stop.
We made wonderful coloured warning to help you. Full Stop.
Well on one hand I get the point, people played with fire. Code should be "correct" by standards that are emerging, but I can predict one thing : before the new "correctness pattern" that enables lots of awesome robust high performing code spreads, there will be chaos.
My first self interrogation is in how much time llvm team can build a completly correct stable compiler without any surprises? It it takes 2 decades, it will be a lot of chaos involved...
My second interrogation is can the code that "is incorrect" per LLVM standard be obtained without rewriting the source code (I guess not), and how much will it costs before all the code is being "corrected". Do we even have the man power to do it?
You see, some C code may be used everyday but are so complex hardly any developers even well paid like to look at them. (openssl, gnutls, libpng, zlib, dhcpd, bind...). And with platform specific ASM, we may discover that code has lost portability, and it may take a lot of time to discover that it is already happening.
Don't we risk another strike of bad news one day like discovering old software/libraries are behaving differently and need to be rewritten and that no one want to do the same effort as libressl especially since some software have a LOT of dependencies on C code (I do not think to loud of PHP or python, or Perl).
Of course there are unit test, but there are so much of them, some tests (like for python on freeBSD with curses) have been disabled, because "no one has the time to fix them". It is ofc a bad example in this precise case, but in the context, it feels like a growing ghettoisation between the CPU/OS/langage with lots of eyeballs/investments, and the old/poor market. Especially non company backed open source software. A smell of obsolescence by attrition of resource to report bugs/rewrite code.
As a normal former experimental physicist I can feel a transition coming, it smells of chaos and instability, and the question is always, how long, how smooth before the new equilibrium if ever we reach it, and what will break in the process? And well since transitions are transitions, we may reach a new equilibrium, but nothing guarantees it will be reversible, hence some stuff may disappear in the process forever.
I don't know why, but I guess the most vulnerable ecosystem to the changes to come is the non commercial open source.
- lmm 11y agoMuch of the transition has already happened - most applications have already moved on from C to safer languages. What's coming is either the replacement of C libraries (Rust, very careful C rewrites), or perhaps bypassing them entirely (OCaml unikernel work). I would fear more for proprietary systems. Open source is relatively innovative and adaptable.
- SFJulie 11y agoStill it sounds like the death of portability. We are kind of crowning the right to rule of the x86 computer industry. llvm is very tied to apple, maybe it can extend to ARM. But it means that some HW platform that may be to old may be difficult to maintain in the future (HPPA, Dec alpha, MIPS, PDP, zseries?). And some computers have life cycle that are more than 10 years. (Expensive industry robots, telco switches, some medical devices, aeronautic/space CPU, radars, some very old mainframe used for accounting, embedded automation devices)... Is this push to obsolescence really cool? Okay critical system already handle the problem, but what about the stuff in the grey zone? Stuff that were not critical but get adopted nonetheless because they just worked and good be updated?
- lmm 11y agoHuh? Higher-level languages are much more portable than C - you only have to port the language runtime, and often someone's done that already. LLVM has a lot of different backends available.
- SFJulie 11y agohum.... well. If you imagine that they are 100% idempotent on every platform and 100% fully supported. It would work. But as I stated in my example python/Perl/C# and probably others are in the language support dropping either some platform or supporting only x% of the feature on some platform... I dare you to access you services using C#/mono on openBSD.
- 11y ago