Is there a payoff for using Large File API?

[Alona]

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

Thank you, Alona

 

[Ian Collins]

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

You should ask this on a group dedicated to the platform where these
function are used. They are not part of standard C, so any answer will
be platform specific.

 

[jacob navia]

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

Thank you, Alona

Look, just think a bit.
1) You are going to access the disk. This unit is incredibly SLOW
compared to RAM/CPU speeds.

2) In a 32 machine, using 64 bit data could be slightly more costly
than using 32 bit data.

3) Any slow down produced by that 64 bit usage will be millions
of times smaller than the time needed to access the disk!

Conclusion:

It doesn't matter at all. Use always the 64 bit functions and
do not worry about this.

 

[Flash Gordon]

Alona wrote, On 17/03/08 20:01:

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

One problem with using the xxx64() functions is that they are not
standard and so are not portable across all implementations. As to other
possible disadvantages, you need to ask in a group that covers the
implementation(s) you are interested in.

 

[santosh]

Alona wrote, On 17/03/08 20:01:

One problem with using the xxx64() functions is that they are not
standard and so are not portable across all implementations.

They are standardised under SUSv3, but they won't be available unless
the underlying system supports large files. So the restriction in
portability is due both to the fact that they are not covered by ISO C
and also the fact that not all systems define them in the first place.

<snip>

 

[Eric Sosman]

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

[...]
It doesn't matter at all. Use always the 64 bit functions and
do not worry about this.

... but be sure not to use gets64(), because it's four
billion times more dangerous than gets(), which is already
too dangerous. You should also avoid fflush64(stdin64),
because its behavior is not standardized and it will do
different things on different systems. Oh, and remember
to cast all your FILE* pointers to FILE64* pointers to
avoid compiler warnings. (See the <stdio62.h64> header
for macros and definitions to make the transition easier.)

 

[jacob navia]

Hello All,

Is there a payoff for using Large File API? Why, for example, wouldn't
one use xxx64() functions in all cases rather than considering either
to use 32-bit or 64-bit API.

[...]
It doesn't matter at all. Use always the 64 bit functions and
do not worry about this.

... but be sure not to use gets64(), because it's four
billion times more dangerous than gets(), which is already
too dangerous. You should also avoid fflush64(stdin64),
because its behavior is not standardized and it will do
different things on different systems. Oh, and remember
to cast all your FILE* pointers to FILE64* pointers to
avoid compiler warnings. (See the <stdio62.h64> header
for macros and definitions to make the transition easier.)

Incredible how much nonsense you can write. You do this for
free or at least you are getting paid for it?

Obviously writing nonsense as "answer" to my posts should
improve your ranking in the clique isn't it?

Great Eric!

Go on. It is you that looks like an idiot, not me.

 

[santosh]

Alona wrote:
Hello All,

Is there a payoff for using Large File API? Why, for example,
wouldn't one use xxx64() functions in all cases rather than
considering either to use 32-bit or 64-bit API.
[...]
It doesn't matter at all. Use always the 64 bit functions and
do not worry about this.

... but be sure not to use gets64(), because it's four
billion times more dangerous than gets(), which is already
too dangerous. You should also avoid fflush64(stdin64),
because its behavior is not standardized and it will do
different things on different systems. Oh, and remember
to cast all your FILE* pointers to FILE64* pointers to
avoid compiler warnings. (See the <stdio62.h64> header
for macros and definitions to make the transition easier.)

Incredible how much nonsense you can write. You do this for
free or at least you are getting paid for it?

Obviously writing nonsense as "answer" to my posts should
improve your ranking in the clique isn't it?

Great Eric!

Go on. It is you that looks like an idiot, not me.

I thought his post was funny. It's obviously meant to be nonsense, well
obvious to most I guess.

 

[Richard Heathfield]

jacob navia said:

Eric Sosman wrote:

... but be sure not to use gets64(), because it's four
billion times more dangerous than gets(), which is already
too dangerous. You should also avoid fflush64(stdin64),

[etc]

Incredible how much nonsense you can write.

*Whoosh*!

 

[George Peter Staplin]

Look, just think a bit.
1) You are going to access the disk. This unit is incredibly SLOW
compared to RAM/CPU speeds.

2) In a 32 machine, using 64 bit data could be slightly more costly
than using 32 bit data.

3) Any slow down produced by that 64 bit usage will be millions
of times smaller than the time needed to access the disk!

Conclusion:

It doesn't matter at all. Use always the 64 bit functions and
do not worry about this.

That's not the answer. See the followup I posted in
comp.unix.programmer. Some systems support 64-bit syscalls, and
structs with their file API, without the need for special 64 suffixed
functions. The programmer generally shouldn't care, as long as the
necessary macros are defined.


George

 

[Walter Roberson]

Incredible how much nonsense you can write. You do this for
free or at least you are getting paid for it?

You are recycling yourself; you used that line on me a couple of weeks
ago (and then conveniently failed to follow-up when I pointed out
the utility in what I had posted.)

 

[Kenny McCormack]

You are recycling yourself; you used that line on me a couple of weeks ago

If the foo sh*ts. We all repeat ourselves, often when the recipient
didn't get it the first time.

(and then conveniently failed to follow-up when I pointed out
the utility in what I had posted.)

I would imagine that we didn't see the utility in what you posted, so
assumed you were just blowing (more) smoke.