On 06/02/2017 02:07 AM, Martin Decky wrote: >> 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.
Let me start my defense by inverting the question. What sort of applications will benefit from an improved but non-standard ftell() and fseek()? 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. 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. 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. Jakub _______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
