Dear all,
I would just like to ask what is the motivation behind the recent surge
of "standardization", i.e. modifying the HelenOS native API to reflect
some external so-called standards.
I mean, most of the changes are obviously fine and maybe even beneficial
(the clean up of the headers and whatnot), but other changes raise some
questions, for example:
* Why do we have to have qsort() and qsort_r()? It's 2017, shouldn't we
strive for our basic API to be always reentrant and thread-safe?
* Why should ftell() return a long instead of a off64_t? What is the
reason for using a signed type when semantically the offset (from the
beginning of the file) is always non-negative? And why do we want to
limit the type to 32 bits on 32 bit platforms?
I always though that our "doctrine" gives us the liberty to ditch or
slightly alter parts of the so-called standards that are stupid,
outdated or otherwise violating the best software engineering practices
of our time (while at the same time keeping our native API similar to
existing APIs where the syntactical or semantic differences can be
neglected in practice).
Are you porting some large piece of software to HelenOS? If so and you
really need to replicate blunders of decades-old APIs in HelenOS, may I
suggest you take the alternative path: Rename our native API symbols to
non-clashing names and implement the replicas of the foreign broken APIs
in separate optional libraries that do not force the brokenness to
everything in HelenOS?
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
