Hi Martin,
please see my comments inline.
"I would just like to ask what is the motivation behind the recent surge
of "standardization","
> Are you porting some large piece of software to HelenOS?
My recent work was in the beginning to fix MGI HelenOS build after a few
months. It's not a new application. Some were regressions in HelenOS
functionality that I was already using (rename(), remove()), others new
functionality required / for the benefit of MGI (qsort, usleep).
When working on qsort() I noticed the header discrepancies so I went on to
resume work in this area. The header refactoring may look intimidating since
it impacts a lot of files (consumers). But in essence these are relatively
small and straightforward changes.
" i.e. modifying the HelenOS native API to reflect
some external so-called standards. "
I think there is some misunderstanding. There is no change in direction or
policy here w.r.t. HelenOS and standards. I just incidentally got around to
do a little bit of work to make HelenOS closer to the model I presented
years ago (we have wiki article on that - HelenOS and standards) and that I
have been working on slowly. There should be no surprise here.
For years I have asserted:
- HelenOS libc may contain features from ISO C as to support standards-
compliant programs as well as HelenOS native APIs that must be named in a
way not to conflict with ISO C APIs
- HelenOS native APIs should not name clash with GNU APIs
- HelenOS might implement useful GNU extensions to ISO C APIs if they are
useful
- HelenOS kernel and boot environments should be consistent with libc
environment (and obey similar rules)
I would also like to remind you some work I already did in this area in the
past (e.g. stdbool.h in libc - but forgot in kernel/boot) without anyone
protesting.
" "
"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 "
Well clearly having ISO C standard features (size_t, NULL, uintN_t) defined
in a proprietary header (different in boot, kernel and userspace) as opposed
to the standard headers (stdbool.h, stddef.h, stdint.h) that form core of
the ISO C freestanding standard is really really silly.
"
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? "
qsort_r is not a reentrant version of qsort (despite the name). It just
allows an extra argument to the compare function, making it slightly more
powerful (C not supporting lambda-abstraction and whatnot). qsort() is
reentrant and thread-safe. qsort() is provided for the benefit of
compatibility with programs that are written against ISO C (e.g. MGI). qsort
_r() is provided, because it's (a) useful (b) it's a GNU extension so again
for the benefit of compatibility.
One thing that may be arguable is whether qsort_r() (and similar GNU
extensions to C standard APIs) should belong in libc or libposix. I think it
should be judged on a case-by-case basis. In general, if this is a GNU
extension of a ISO API, it mostly seems more logical to put it in the same
place as the ISO C API (otherwise it would leak implementation details
across library boundaries).
"* 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?"
Yes, this one is a little problematic, I wanted to discuss with Jakub.
Having ftell return off64_t is wrong (because it conflicts with the
standard). It's correct to fix it. ftell() was always supposed to be the ISO
C ftell. If you want something else, use a native HelenOS API. However, be
careful since ftell is broken w.r.t. large files. So it probably shouldn't
be used anywhere in HelenOS. Also might want to provide ftello somewhere
(where?)
"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). "
I always stated I am all for making better APIs. But they must *not* have
names same or similar (easily confused with) the ISO C APIs. That's the road
to compatibility hell. That's just the way to make things not work, confuse
people, etc.
Windows does it this way too - they have their own (sometimes very good)
APIs, but they *never* conflict with ISO APIs (they use different,
nonconflicting naming conventions).
> 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? "Practically every interface I ever introduced used
the naming convention prefix_something. The absolute majority of HelenOS
native APIs does not clash with a standard API. If it does, it's a shadow of
the past. But as you can see, we are working on that... slowly
I don't think it's necessary to put in a separate library. That would only
make things more complicated. C library was always a mixture of C-standard
stuff and OS stuff. I don't necessarily see a problem with that.
To reiterate, I am surprised that you are surprised. I don't see current
work as anything new or out of the ordinary.
Best regards,
Jiri
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
