This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fseek() vs. fseeko()


On 06/20/2012 04:07 PM, Joel Sherrill wrote:
On 06/20/2012 08:54 AM, Ralf Corsepius wrote:
On 06/20/2012 03:41 PM, Joel Sherrill wrote:
On 06/19/2012 09:42 AM, Sebastian Huber wrote:
On 06/19/2012 04:08 PM, Corinna Vinschen wrote:
Along these lines, fgetpos and fsetpos are a bit tricky since they
depend on the definition of fpos_t in include/stdio.h. Right now,
only Cygwin defines fpos_t as 64 bit type in stdio.h, all other
targets define fpos_t as 32 bit and fpos64_t as 64 bit type to make
a clear distinction between the 32 bit and the 64 bit set of
functions.
Speaking for myself, I would like the methods to default to all 64-bit
versions on RTEMS (when the CPU defaults to 64-bit).
This is non-reasonable, because it's unsuiteable for "small" targets,
ineffective on some architectures and a waste of resources for some
applications.
Hence the parenthetical phrase "(when the CPU defaults to 64-bit)"

We choose 32-bit or 64-bit off_t as the default on a per CPU basis
and whichever it is, all methods without an explicit number in the
name should use the default type.
RTEMS has this in<machine/_types.h>:
FWIW I think that list to use 64-bit types should be longer.
This list is hand-crafted for "big targets", based on user-demand.
I have done two ports in the past few months and never looked
at that list. Both should have been on the 64-bit list.

Well, you did not ask nor mention it anywhere ;-)


It is another issue entirely but I think we need to make a
conscious decision for every target.

As I wrote above this would be un-wise. Embedded application running on say avr/nios2/h8300/sh based-systems with very few 100kB of RAM will hardly ever need 64bit off_t's.


Esp. _you_, the person who often has added questionable measures to RTEMS "to reduce memory overhead" should know why.

Of course, this doesn't invalidate any reasoning to make off_t's configuration-time configurable - It would be nice-to-have. Unfortunately, this is not trivial to implement into newlib's configuration.

Ralf



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]