I'm not involved in the changes, but I always thought that this "doctrine" is incredibly damaging to HelenOS and the primary reason for the general lack of contributors.
I don't see a lack of contributors. A lack of driving force in the recent years -- yes, I can see that. But some 70 contributors in total is fine for me.
Nothing good happens when you ditch and namespace block preexisting standard APIs.
I don't block it. I have nothing against the foreign APIs being implemented as optional APIs in HelenOS. But the primary goal of HelenOS (for me, that is) is not to follow a path somebody else walked before us. There are other microkernel projects that focus on this and there are arguably much better at it than we can ever be.
The problems you are naming are intrinsic to the C programming language
No, they are not. Intrinsic to C programming language -- those are things such as NULL-terminated strings and maybe some function calls that the C compiler actually does emit when generating code (e.g. memcpy()). But qsort() and ftell() are far from it. Those are just some library functions that someone defined many years ago, but they have little to do with the core language.
Of course, I acknowledge that the boundary can be somewhat fuzzy in some situations (i.e. the names of some header files), but while it would be hard to have a working C run-time with a modified memcpy() (without patching the compiler itself), it is demonstrably easy to have a working C run-time with a different ftell().
and the only reason C is useful at all is because of the vast quantity of existing code.
I strongly disagree. For HelenOS, C is not useful because of a vast quantity of existing code, but merely because of the existence of a decent C compiler suite (and related tools) that supports all the platforms we target, jointly with some historical reasons (yes, ironically, due to the current size of the HelenOS code base it is unfortunately no longer a lean prototype that could be rewritten in a week).
Again, I not saying that we should never have ported applications that obviously require a foreign API. But I see no reason why this foreign API should be enforced as our native API.
? So you create a
different language that shares all of C's problems, but doesn't support any of the existing code? How does that make sense?
It does make sense. Even if it is not a perfect new world, it's a gradual improvement that at least eliminates some of the blunders that could be eliminated easily.
I personally like C (the core language) precisely because it binds to the run-time only loosely, compared to many other languages where you have to implement a huge API precisely according to some predefined specification to compile any non-trivial program.
But despite that, I still see our use of C more akin to making a virtue out of necessity. And precisely this is the reason why we don't have to be so pedantic about the API.
M.D. _______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
