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 am NOT protesting against all changes in general, especially not the
header naming changes. I question only some specific changes that I
consider as regressions to a worse state.
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.
Again, I believe nobody objected to that part.
qsort_r is not a reentrant version of qsort (despite the name).
OK, then it's fine. The name of the qsort_r() symbol is still confusing,
but I can live with that.
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?)
But why do we have to be so pedantic here? If our ftell() returns
off64_t, it is still source code compatible with 99 % of code which uses
it thanks to the implicit conversion from off64_t to long. Yes, there
might be corner cases like using ftell() as a function pointer or
possibly different behaviour when an expression targeting a 32bit
platform does not overflow as expected, but those can be either easily
solved or are questionable in the first place (since it might be an
undefined behaviour).
Imagine you could go back in time and affect the proposal of the ISO C
with your current knowledge. Would you really keep the return type of
ftell() as long?
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.
Yes, this is definitively the safest approach. So renaming our fseek()
and ftell() to something different (and possibly implementing
ISO-compliant fseek() and ftell() separately if needed) is definitively
the best approach.
Turning our modified ftell() into ISO-compliant ftell() without
preserving the nicer semantics of our modified ftell() (as a different
symbol) is the worst approach (IMHO).
Keeping our modified ftell() as it was is not the best approach, but
still acceptable for me and definitively better than just removing the
functionality, because it hardly breaks anything in practice.
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.
There is one important reason to keep the native and legacy interfaces
separated in different libraries: So that you can be sure (at compile
time) that you are only using the native API and you don't accidentally
use anything that might be broken due to the compatibility with the
legacy API.
To reiterate, I am surprised that you are surprised. I don't see current
work as anything new or out of the ordinary.
Again, the overall approach does not surprise me and I don't object to
it. I was just surprised by some individual changesets that I considered
as a pedantic adherence to a legacy API while at the same time removing
our nicer semantics without a replacement.
Either it's compatible with the standard and then it can use the standard name.
Or it's not and it should use a unique name.
Yes, but there are surely different degrees of compatibility.
Having "long ftell(..)" is a pedantic degree of compatibility with ISO
C. Having "off64_t ftell(..)" is still practically compatible with ISO C
in 99 % of cases, but the semantics is better.
M.D.
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
