Thou shalt have no other gods before the ANSI C standard 1402

More like it doesn't look far enough ahead, which you sort of say in different words later on.

fnewseek() fnewread() fnewwrite() fnewtell() etc.

(Feel free to come up with a better name that doesn't have the letters 64 in it, ala the Linux extensions)

All taking an offt. Add some sort of

#define OFFTONTHISPLATFORM nnn * bits, always unsigned *

So programmers can easily determine what size it is as well.

Maybe also add a jumbocounterfromhellt, the largest thing the compiler can support as an int, so if they support 128-bit int, you can have at it as well instead of having to use an add-on extended precision library. :-)

While at it, add a printf format specifier that likes offt, akin to %z for sizet. Then all you need do is figure out a way to magically get all those the compiler vendors that have refused (or not been compelled) to provide even C99 support to add this.

Since C06 or whatever it will be is supposedly just around the corner, now would be a good time to try and fix this, but they seem to be (I haven't read minutes, I am sure somebody else here would know better anyway) fixated on security, security, security.

We don't need a file offset data type to have any intrinsic "bit width" at all, but be the largest the implementation can provide.

If you intend to support files that large. For an .ini file or something, it's not a problem. But, I have, as I am sure others have done, created a set of wrapper functions to allow me to the logical equivalent of the above on every platform I have to support so that I can have apps use the "grand unified file theory" to access jumbo files.

-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig