Hi Jakub,
Let me start my defense by inverting the question. What sort of
applications will benefit from an improved but non-standard ftell() and
fseek()?
Until our non-standard implementation is back under a different name:
Any native HelenOS application, plus potentially applications that
actually store the return value of ftell() in something more appropriate
than a long.
After our non-standard implementation is back under a different name:
Obviously none.
These interfaces are provided so that software such as sbi, MGI,
bithenge, tetris and the coastline stuff can be ported to HelenOS. But
let me remind you that these application and libraries have already had
to cope with the limitations of the standard ftell() and fseek(), so
there is no real benefit here.
Again, not necessarily. They can easily do something like:
uint64_t offset = ftell(..);
In that case they might still benefit. I know that it is mostly
academical, but I want to point out that there are indeed many degrees
of compatibility. Pedantic compatibility is but one of the degrees.
Choosing the right degree is always some kind of trafe-off.
I'd argue that if an amphibious or
plainly third party standards-compliant application aspires to be ready
for large files, it does not use ftell() and fseek() anyway.
Yes, possibly.
The native HelenOS applications should not be using these interfaces at
all or at least they should be very well aware of their limitations. So
perhaps using them for processing configuration files is still ok, but
using them for working with arbitrarily large files (such as in the
shell) is not.
I agree.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
