Is there a payoff for using Large File API?

Discussion in 'C Programming' started by Alona, Mar 17, 2008.

  1. Alona

    Alona Guest

    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
    Alona, Mar 17, 2008
    #1
    1. Advertising

  2. Alona

    Ian Collins Guest

    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.
    >

    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.

    --
    Ian Collins.
    Ian Collins, Mar 17, 2008
    #2
    1. Advertising

  3. Alona

    jacob navia Guest

    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.
    >
    > 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.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 17, 2008
    #3
  4. Alona

    Flash Gordon Guest

    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.
    --
    Flash Gordon
    Flash Gordon, Mar 17, 2008
    #4
  5. Alona

    santosh Guest

    Flash Gordon wrote:

    > 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.


    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>
    santosh, Mar 17, 2008
    #5
  6. Alona

    Eric Sosman Guest

    jacob navia wrote:
    > 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.)

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 18, 2008
    #6
  7. Alona

    jacob navia Guest

    Eric Sosman wrote:
    > jacob navia wrote:
    >> 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.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 18, 2008
    #7
  8. Alona

    santosh Guest

    jacob navia wrote:

    > Eric Sosman wrote:
    >> jacob navia wrote:
    >>> 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.
    santosh, Mar 18, 2008
    #8
  9. jacob navia said:

    > Eric Sosman wrote:


    <snip>
    >>
    >> ... 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*!

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Mar 18, 2008
    #9
  10. jacob navia wrote:
    > 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.
    >>
    >> 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.



    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
    George Peter Staplin, Mar 19, 2008
    #10
  11. In article <froimg$u8c$>, jacob navia <> wrote:

    >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.)
    --
    "He wove a great web of knowledge, linking everything together,
    and sat modestly at a switchboard at the center, eager to help."
    -- Walter Kerr
    Walter Roberson, Mar 20, 2008
    #11
  12. In article <frud9t$cp4$>,
    Walter Roberson <-cnrc.gc.ca> wrote:
    >In article <froimg$u8c$>, jacob navia <> wrote:
    >
    >>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


    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.
    Kenny McCormack, Mar 20, 2008
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    6,029
    Chris Uppal
    Jun 20, 2006
  2. ray
    Replies:
    1
    Views:
    1,298
    Robert Kern
    Jun 4, 2010
  3. Ketchup
    Replies:
    1
    Views:
    231
    Jan Tielens
    May 25, 2004
  4. Bob Lu
    Replies:
    0
    Views:
    115
    Bob Lu
    Jun 25, 2009
  5. Replies:
    5
    Views:
    848
    Xho Jingleheimerschmidt
    Apr 2, 2009
Loading...

Share This Page