FREAD fails on files >4GB

[Richie Kernagan]

Howdy

Problem with the fread() call on MS Visual Studio 2005 running under Win 64.

The parameters to fread size and count are both size_t ie 64 bits. Even
so the call fails when the size arg is greater than 4GB (ie exceeds 32
bit unsigned value).

Any suggestions.

Thanks in advance.

 

[Walter Roberson]

Problem with the fread() call on MS Visual Studio 2005 running under Win 64.

Hmmm, then why post to comp.compilers.lcc ???

The parameters to fread size and count are both size_t ie 64 bits. Even
so the call fails when the size arg is greater than 4GB (ie exceeds 32
bit unsigned value).

Either there is a bug in your code (which you don't show us)
or there is a bug in the MS Visual Studio 2005 support library.
If you wish to investigate the possibility of a bug in
MS Visual Studio 2005 then you should do so in an OS-specific
forum or on one of microsoft's web sites. If you wish to investigate
that the possibility of a bug in your code, you will need to post
compilable code that we could test with... preferrably code that
specifically outputs the size of size_t so that we can see with
our own eyes that you haven't accidently been mistaken about
how big size_t is on the system.

 

[vippstar]

Howdy

Problem with the fread() call on MS Visual Studio 2005 running under Win 64.

The parameters to fread size and count are both size_t ie 64 bits. Even
so the call fails when the size arg is greater than 4GB (ie exceeds 32
bit unsigned value).

So what? fread can succeed or fail.

 

[Antoninus Twink]

So what? fread can succeed or fail.

Great. Just great.

When an implementation deviates by a tiny fraction from the golden
tablets of The Standard, the people here come down on it like a ton of
bricks. But as long as it obeys the letter of the law, noone minds how
poor the quality of implementation might be.

Do malloc() and fopen() always return NULL? No problem! That's OK
according to The Standard. Of course it makes no difference to "vip
star" and his friends, as it's clear they never actually program C in
the real world, so a program in the abstract machine that always
terminates gracefully with an informative error message like
"Program failed at line 1 - this implementation always returns NULL to
malloc()"
is just fine for them...just as long as the return type of main() is
right.

 

[Walter Roberson]

Great. Just great.

When an implementation deviates by a tiny fraction from the golden
tablets of The Standard, the people here come down on it like a ton of
bricks. But as long as it obeys the letter of the law, noone minds how
poor the quality of implementation might be.

The quality of any particular implementation is relevant to
newsgroups that deal with that particular implementation, and not
relevant to comp.lang.c, which deals with the C language rather than
with implementations.

 

[santosh]

Howdy

Problem with the fread() call on MS Visual Studio 2005 running under
Win 64.

The parameters to fread size and count are both size_t ie 64 bits.
Even so the call fails when the size arg is greater than 4GB (ie
exceeds 32 bit unsigned value).

Any suggestions.

Thanks in advance.

In many cases additional flags must be defined for an implementation to
support files larger than 4 Gb. Verify that you have done so. Any such
requirement should be documented in the reference documentation for
your implementation.

Also post your actual code that fails (as minimal an example as
possible), along with details of fread's input and output, and the
exact error that you have detected.

 

[Richard Bos]

Hmmm, then why post to comp.compilers.lcc ???

Crossposted to a newsgroup where this clearly doesn't belong.

Added a follow-up (so the crosspost was no accident or lack of thought).

Used _that_ nick.


Oh my, what could possibly be happening here?

Richard