On Fri, 2017-06-02 at 15:47 +0200, Jiří Zárevúcky wrote: > On 2 June 2017 at 13:45, Martin Decky <[email protected]> wrote: > > Hi Jiri S., > > > > > Note: > > > https://docs.oracle.com/cd/E23824_01/html/821-1465/ftell-3c.html#scrolltoc > > > > > > On Solaris, at least, it does not overflow, it returns EOVERFLOW > > > > > > OK, so either this is the standard behaviour which we don't implement, thus > > we still deviate from the standard and implement a non-standard ftell(). Or > > Solaris is implementing a non-standard ftell(). > > > > Either way, how cool is that? :-D > > > > The core C standard doesn't actually specify what happens on overflow, > so this is actually implementation-defined detail, not a non-standard > behavior. > However, POSIX mandates this behavior. > > > > > Conversely the *benefit* of ftell returning off64_t for a 3rd party > > > portable software is nil. It has two choices: either it is fine with not > > > being largefile aware and uses ftell() on all platforms, or it decides to > > > be > > > largefile aware and uses OS-specific method on all platforms. > > > > > > Or it might use ftell(), but still store the return value in a 64bit integer > > for whatever reason. > > > > But again, this discussion is mostly academic once we have our previous > > implementation under a different name back. > > > > Despite some faulty designs, the POSIX extensions to the C standard > library actually solve the problems you want to solve. > ftello()/fseeko() as defined in POSIX are pretty much identical to the > functions we had before. > Ironicaly, the way to satisfy everyone here is to follow the POSIX > specification for stdio. > > > > I thought we were clear that HelenOS is written in C, not in some weird > > > language that just happens to be similar. That would never work. > > > > > > In that case we disagree on the operational definition of C. For me, C is > > the core language (syntax, semantics of its intrinsic language constructs, > > run-time bindings required by the compiler). > > > > The Standard C Library is an extension of the core C language that I > > consider mostly replaceable (naturally except the function calls that are > > emitted by the compiler itself). > > > > I'd argue that the standard function library of any language is just > as important as the core language. > Core syntax and semantics are easy, you can memorize the whole thing > in an afternoon if you want. > Learning the APIs is usually more of a task.
I agree with this part. Saying "we have a libc, but it's not quite libc. you'll be ok most of the time, but there are gotchas that will screw you" is not very welcoming attitude. IMO most of the discussion could be avoided if what is called 'libc' wasn't the native helenos runtime library. have a native c runtiem library (called helrun, or whatever), and keep libc close to standard. Jan > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
