fopen and fclose?

Discussion in 'C++' started by kathy, Feb 3, 2006.

  1. kathy

    kathy Guest

    if fopen failed, does it necessary to call fclose?

    I see an example like this:
    ....
    stream = fopen(...);
    if(stream == NULL)
    {
    ....
    }
    else
    {
    ....
    }
    fclose(stream);
    ....

    By my understanding, it should like this:
    ....
    stream = fopen(...);
    if(stream == NULL)
    {
    ....
    }
    else
    {
    ....
    fclose(stream);
    }
    kathy, Feb 3, 2006
    #1
    1. Advertising

  2. kathy wrote:
    > if fopen failed, does it necessary to call fclose?


    No. And actually I can't find any description of what's going to happen
    if you pass a null pointer to 'fclose'. Conclusion: it's undefined
    behaviour and should be avoided. IOW, you must _not_ call 'fclose' for
    a pointer obtained from 'fopen' if opening failed (and null pointer is
    returned).

    > [..]


    V
    Victor Bazarov, Feb 3, 2006
    #2
    1. Advertising

  3. kathy

    DraakUSA Guest

    It should be like this:

    stream = fopen(...);
    if (stream == NULL)
    {
    ...
    }
    else
    {
    ...
    fclose(stream);
    }

    fclose'ing a NULL pointer is undefined and could cause problems.
    fclose a stream ONLY iff it is a valid open stream.
    DraakUSA, Feb 3, 2006
    #3
  4. kathy

    mlimber Guest

    kathy wrote:
    > if fopen failed, does it necessary to call fclose?


    It doesn't hurt anything to call fclose with a null pointer, and the
    function will return an error code if it fails to close the supplied
    file.

    >
    > I see an example like this:
    > ...
    > stream = fopen(...);
    > if(stream == NULL)
    > {
    > ...
    > }
    > else
    > {
    > ...
    > }
    > fclose(stream);
    > ...
    >
    > By my understanding, it should like this:
    > ...
    > stream = fopen(...);
    > if(stream == NULL)
    > {
    > ...
    > }
    > else
    > {
    > ...
    > fclose(stream);
    > }


    Your way is preferable, IMHO, but I think either is legal. Better still
    might be to use std::fstream instead. :)

    Cheers! --M
    mlimber, Feb 3, 2006
    #4
  5. kathy

    mlimber Guest

    mlimber wrote:
    > kathy wrote:
    > > if fopen failed, does it necessary to call fclose?

    >
    > It doesn't hurt anything to call fclose with a null pointer


    I stand corrected.
    mlimber, Feb 3, 2006
    #5
  6. kathy

    mlimber Guest

    mlimber wrote:
    > mlimber wrote:
    > > kathy wrote:
    > > > if fopen failed, does it necessary to call fclose?

    > >
    > > It doesn't hurt anything to call fclose with a null pointer

    >
    > I stand corrected.


    Hmm. On second... er, third thought, I'm not sure what the standard
    mandates, but the IRIX 6.5 manpages do say: "For fclose, EOF is
    returned if stream is NULL, or stream is not active, or there was an
    error when flushing buffered writes, or there was an error closing the
    underlying file descriptor."

    Cheers! --M
    mlimber, Feb 3, 2006
    #6
  7. kathy

    Default User Guest

    mlimber wrote:


    > Hmm. On second... er, third thought, I'm not sure what the standard
    > mandates, but the IRIX 6.5 manpages do say: "For fclose, EOF is
    > returned if stream is NULL, or stream is not active, or there was an
    > error when flushing buffered writes, or there was an error closing the
    > underlying file descriptor."


    IRIX man pages are not the Standard. There's no similar wording in
    either the C or C++ standards.

    Here's the wording from the C99 draft standard:

    7.19.5.1 The fclose function

    Synopsis

    [#1]

    #include <stdio.h>
    int fclose(FILE *stream);

    Description

    [#2] The fclose function causes the stream pointed to by
    stream to be flushed and the associated file to be closed.
    Any unwritten buffered data for the stream are delivered to
    the host environment to be written to the file; any unread
    buffered data are discarded. The stream is disassociated
    from the file. If the associated buffer was automatically
    allocated, it is deallocated.

    Returns

    [#3] The fclose function returns zero if the stream was
    successfully closed, or EOF if any errors were detected.



    Brian


    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Feb 4, 2006
    #7
  8. Default User <> wrote:

    > 7.19.5.1 The fclose function


    > Returns
    >
    > [#3] The fclose function returns zero if the stream was
    > successfully closed, or EOF if any errors were detected.


    Out of interest, could one not assume that "any error" will include
    having passed 0 to fclose .. ?

    regards
    --
    jb

    (reply address in rot13, unscramble first)
    Jakob Bieling, Feb 4, 2006
    #8
  9. kathy

    Default User Guest

    Jakob Bieling wrote:

    > Default User <> wrote:
    >
    > > 7.19.5.1 The fclose function

    >
    > > Returns
    > >
    > > [#3] The fclose function returns zero if the stream was
    > > successfully closed, or EOF if any errors were detected.

    >
    > Out of interest, could one not assume that "any error" will include
    > having passed 0 to fclose .. ?


    Do you have some sort of support for that?

    I think the fact that it differs from the implementation-specific man
    page should tell you what you need to know.

    Closing a null FILE* is UB.


    Brian


    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Feb 4, 2006
    #9
  10. On 3 Feb 2006 12:05:06 -0800, "kathy" <> wrote:

    >if fopen failed, does it necessary to call fclose?
    >
    >I see an example like this:
    >...
    >stream = fopen(...);
    >if(stream == NULL)
    >{
    >...
    >}
    >else
    >{
    >...
    >}
    >fclose(stream);
    >...
    >
    >By my understanding, it should like this:
    >...
    >stream = fopen(...);
    >if(stream == NULL)
    >{
    >...
    >}
    >else
    >{
    >...
    >fclose(stream);
    >}



    else {
    ....
    if (fclose(stream) == 0) {
    // success
    } else {
    // error
    }
    }

    Best wishes,
    Roland Pibinger
    Roland Pibinger, Feb 4, 2006
    #10
  11. Default User <> wrote:
    > Jakob Bieling wrote:
    >
    >> Default User <> wrote:
    >>
    >>> 7.19.5.1 The fclose function

    >>
    >>> Returns
    >>>
    >>> [#3] The fclose function returns zero if the stream was
    >>> successfully closed, or EOF if any errors were detected.

    >>
    >> Out of interest, could one not assume that "any error" will include
    >> having passed 0 to fclose .. ?

    >
    > Do you have some sort of support for that?


    The only support is that paragraph you cited, since I do not call
    fclose with a 0-pointer either (nor would I encourage anyone to do so).

    Guess I am just complaining about them writing "any error", when in
    fact passing a 0-pointer is not covered.

    > I think the fact that it differs from the implementation-specific man
    > page should tell you what you need to know.



    Agreed.

    regards
    --
    jb

    (reply address in rot13, unscramble first)
    Jakob Bieling, Feb 4, 2006
    #11
  12. kathy

    Default User Guest

    Jakob Bieling wrote:


    > Guess I am just complaining about them writing "any error", when in
    > fact passing a 0-pointer is not covered.



    Many functions, especially those inherited from C, accept null pointers
    without defined behavior. Notably most of the C-style string functions.



    Brian
    Default User, Feb 5, 2006
    #12
  13. kathy

    Ron Natalie Guest

    Default User wrote:
    > Jakob Bieling wrote:
    >
    >
    >> Guess I am just complaining about them writing "any error", when in
    >> fact passing a 0-pointer is not covered.

    >
    >
    > Many functions, especially those inherited from C, accept null pointers
    > without defined behavior. Notably most of the C-style string functions.
    >
    >

    Absolutely, completely wrong.

    7.1.4 of the C standard says that:

    If an argument to a function has an invalid value (such as a value
    outside the domain of the function, or a pointer outside the address
    space of the program, OR A NULL POINTER, or a pointer to on-modifiable
    storage when the corresponding parameter is not const-qualified) or a
    type (after promotion) not expected by a function with variable number
    of arguments, the behavior is undefined.

    The string functions as does fclose, do not specify behavior for
    being passed null behavior, hence by 7.1.4 the behavior is undefined.
    Ron Natalie, Feb 14, 2006
    #13
  14. kathy

    Ben Pope Guest

    Ron Natalie wrote:
    > Default User wrote:
    >> Jakob Bieling wrote:
    >>
    >>
    >>> Guess I am just complaining about them writing "any error", when in
    >>> fact passing a 0-pointer is not covered.

    >>
    >>
    >> Many functions, especially those inherited from C, accept null pointers
    >> without defined behavior. Notably most of the C-style string functions.
    >>
    >>

    > Absolutely, completely wrong.
    >
    > 7.1.4 of the C standard says that:
    >
    > If an argument to a function has an invalid value (such as a value
    > outside the domain of the function, or a pointer outside the address
    > space of the program, OR A NULL POINTER, or a pointer to on-modifiable
    > storage when the corresponding parameter is not const-qualified) or a
    > type (after promotion) not expected by a function with variable number
    > of arguments, the behavior is undefined.
    >
    > The string functions as does fclose, do not specify behavior for
    > being passed null behavior, hence by 7.1.4 the behavior is undefined.


    I think you two are in violent agreement.

    :p

    Ben Pope
    --
    I'm not just a number. To many, I'm known as a string...
    Ben Pope, Feb 14, 2006
    #14
  15. kathy

    Default User Guest

    Ron Natalie wrote:
    > Default User wrote:
    > > Jakob Bieling wrote:
    > >
    > >
    > >> Guess I am just complaining about them writing "any error", when in
    > >> fact passing a 0-pointer is not covered.

    > >
    > >
    > > Many functions, especially those inherited from C, accept null pointers
    > > without defined behavior. Notably most of the C-style string functions.
    > >
    > >

    > Absolutely, completely wrong.


    I don't think so!

    > 7.1.4 of the C standard says that:
    >
    > If an argument to a function has an invalid value (such as a value
    > outside the domain of the function, or a pointer outside the address
    > space of the program, OR A NULL POINTER, or a pointer to on-modifiable
    > storage when the corresponding parameter is not const-qualified) or a
    > type (after promotion) not expected by a function with variable number
    > of arguments, the behavior is undefined.


    Which is what I said, more or less.

    > The string functions as does fclose, do not specify behavior for
    > being passed null behavior, hence by 7.1.4 the behavior is undefined.


    That's what I said, "without defined behavior".

    I believe you misread what I wrote. Probably my phrasing wasn't the
    best.



    Brian
    Default User, Feb 14, 2006
    #15
  16. kathy

    Default User Guest

    Ben Pope wrote:

    > Ron Natalie wrote:
    > > Default User wrote:


    > > > Many functions, especially those inherited from C, accept null
    > > > pointers without defined behavior. Notably most of the C-style
    > > > string functions.


    > > The string functions as does fclose, do not specify behavior for
    > > being passed null behavior, hence by 7.1.4 the behavior is
    > > undefined.

    >
    > I think you two are in violent agreement.



    I believe so. My phrasing "without defined behavior" probably threw Ron
    off in his reading.

    I might screw up in the details of C++, but I'm unlikely to make a
    fundamental error in C :)



    Brian
    Default User, Feb 14, 2006
    #16
  17. kathy

    Ron Natalie Guest

    Default User wrote:
    > Ben Pope wrote:
    >
    >> Ron Natalie wrote:
    >>> Default User wrote:

    >
    >>>> Many functions, especially those inherited from C, accept null
    >>>> pointers without defined behavior. Notably most of the C-style
    >>>> string functions.

    >
    >>> The string functions as does fclose, do not specify behavior for
    >>> being passed null behavior, hence by 7.1.4 the behavior is
    >>> undefined.

    >> I think you two are in violent agreement.

    >
    >
    > I believe so. My phrasing "without defined behavior" probably threw Ron
    > off in his reading.
    >


    Yes there term "accept" allowed me to gloss over the difference between
    "defined" and "undefined". We are in "violent agreement."
    Ron Natalie, Feb 15, 2006
    #17
  18. kathy

    Default User Guest

    Ron Natalie wrote:

    > Default User wrote:


    > > I believe so. My phrasing "without defined behavior" probably threw
    > > Ron off in his reading.
    > >

    >
    > Yes there term "accept" allowed me to gloss over the difference
    > between "defined" and "undefined". We are in "violent agreement."


    I was trying to avoid saying the Standard said it was UB, because in
    most of these cases it just doesn't address what happens when you pass
    in NULL. So I ended up with fairly clunky language that needed a
    rewrite editor.



    Brian
    Default User, Feb 15, 2006
    #18
    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. Trying_Harder

    fgets,fopen, fclose

    Trying_Harder, Aug 26, 2003, in forum: C Programming
    Replies:
    5
    Views:
    670
    John Bode
    Sep 3, 2003
  2. prama

    Re: Question about fopen, fput, fclose?

    prama, Aug 26, 2003, in forum: C Programming
    Replies:
    5
    Views:
    1,735
    Jack Klein
    Aug 28, 2003
  3. Peter Shaggy Haywood

    Re: Question about fopen, fput, fclose?

    Peter Shaggy Haywood, Aug 30, 2003, in forum: C Programming
    Replies:
    0
    Views:
    386
    Peter Shaggy Haywood
    Aug 30, 2003
  4. lihua
    Replies:
    19
    Views:
    909
    CBFalconer
    Jul 7, 2005
  5. David Mathog

    fclose then fopen equivalent for stdout?

    David Mathog, Oct 25, 2006, in forum: C Programming
    Replies:
    20
    Views:
    1,984
    Jordan Abel
    Oct 27, 2006
Loading...

Share This Page