fwrite() does not write data to file

Discussion in 'C Programming' started by arnuld, Sep 2, 2008.

  1. arnuld

    arnuld Guest

    WANTED: Even if I do Ctrl-C in the middle of fgets(), fwrite() should
    write the previously entered data to a file (except if I hit the file-size
    limit)


    PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does not
    write the data to the file.


    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <unistd.h>

    enum { INPUT_SIZE = 5 };


    FILE* fp;

    void write_to_file( const char* );


    int main( void )
    {
    char arrc[INPUT_SIZE];

    memset( arrc, '\0', INPUT_SIZE );

    while( fgets(arrc, INPUT_SIZE, stdin) )
    {
    write_to_file( arrc );
    }


    return EXIT_SUCCESS;
    }




    void write_to_file( const char* arrc )
    {
    int arr_size;
    long fwrite_bytes;

    arr_size = strlen(arrc );
    ++arr_size;

    if( ! (fp = fopen("zzz.txt", "a")) )
    {
    perror("FOPEN ERROR\n");
    exit( EXIT_FAILURE );
    }

    fwrite_bytes = fwrite( arrc, 1, arr_size, fp);

    printf("fwrite_bytes = %ld\n", fwrite_bytes);

    if( arr_size != fwrite_bytes )
    {
    perror("FWRITE ERROR");
    exit( EXIT_FAILURE );
    }

    /*
    if( fclose(fp) )
    {
    perror("CLOSE ERROR\n");
    }
    */
    }


    =============== OUTPUT =====================
    [arnuld@dune CLS]$ gcc -ansi -pedantic -Wall -Wextra check_FILE_IO.c
    [arnuld@dune CLS]$ ./a.out
    lo
    fwrite_bytes = 4

    [arnuld@dune CLS]$ cat zzz.txt
    [arnuld@dune CLS]$


    In only these 3 cases, data gets written:

    1) Remove the comments from the fclose(). I mean do a proper fclose().
    2) You do proper exit using Ctrl-D.
    3) User enters data more than the INPUT_SIZE.

    but I don't want to close the file every time I have data. I want to keep
    it open till I hit the size limit. The problem with fclose() is, if the
    data entered is 2 bytes on each call, then it will take 500 openings and
    closings, which will be very CPU intensive I think. I want this
    program to be efficient in terms of CPU, memory is not the problem
    here, I have got enough of it. I need to keep the file open but in doing
    so a sudden quit using Ctrl-C discards everything user entered.


    Any solution to the problem ?




    --
    www.lispmachine.wordpress.com
    my email is @ the above blog.Google Groups is Blocked. Reason: Excessive Spamming
    arnuld, Sep 2, 2008
    #1
    1. Advertising

  2. arnuld

    Guest

    On Sep 2, 10:50 am, arnuld <> wrote:
    > WANTED: Even if I do Ctrl-C in the middle of fgets(), fwrite() should
    > write the previously entered data to a file (except if I hit the file-size
    > limit)
    >
    > PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does not
    > write the data to the file.


    ^C typically kills the process. It's not possible to do what you want.

    <snip>
    , Sep 2, 2008
    #2
    1. Advertising

  3. arnuld <> writes:
    [...]
    > but I don't want to close the file every time I have data. I want to keep
    > it open till I hit the size limit. The problem with fclose() is, if the
    > data entered is 2 bytes on each call, then it will take 500 openings and
    > closings, which will be very CPU intensive I think. I want this
    > program to be efficient in terms of CPU, memory is not the problem
    > here, I have got enough of it. I need to keep the file open but in doing
    > so a sudden quit using Ctrl-C discards everything user entered.
    >
    >
    > Any solution to the problem ?


    fflush().

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 2, 2008
    #3
  4. arnuld

    arnuld Guest

    > On Tue, 02 Sep 2008 08:13:07 +0000, Richard Heathfield wrote:

    > .... SNIP....


    > fwrite_bytes = fwrite( arrc, 1, arr_size, fp);
    > if(fflush(fp) == EOF)
    > {
    > something went wrong


    > If you mean the data processed by previous fgets calls, fflush should
    > fix that.



    yes, I meant exactly that and hey... Richard, it works :)


    --
    www.lispmachine.wordpress.com
    my email is @ the above blog.
    Google Groups is Blocked. Reason: Excessive Spamming
    arnuld, Sep 2, 2008
    #4
  5. wrote:
    > On Sep 2, 10:50 am, arnuld <> wrote:
    >> WANTED: Even if I do Ctrl-C in the middle of fgets(), fwrite()
    >> should write the previously entered data to a file (except if I hit
    >> the file-size limit)
    >>
    >> PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does
    >> not write the data to the file.

    >
    > ^C typically kills the process. It's not possible to do what you want.


    ^C typically (in UNIX) sends a SIGINT, which you could catch or even ignor.
    But that would be off topic here...

    Bye, Jojo
    Joachim Schmitz, Sep 2, 2008
    #5
  6. Richard Heathfield wrote:
    > Joachim Schmitz said:
    >
    >> wrote:
    >>> On Sep 2, 10:50 am, arnuld <> wrote:
    >>>> WANTED: Even if I do Ctrl-C in the middle of fgets(), fwrite()
    >>>> should write the previously entered data to a file (except if I hit
    >>>> the file-size limit)
    >>>>
    >>>> PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does
    >>>> not write the data to the file.
    >>>
    >>> ^C typically kills the process. It's not possible to do what you
    >>> want.

    >>
    >> ^C typically (in UNIX) sends a SIGINT, which you could catch or even
    >> ignor. But that would be off topic here...

    >
    > Why? SIGINT is a standard signal. See 4.7 of C89 or 7.14 of C99.


    Well, because I thought it to be POSIX.

    Thanks for the correction.

    Bye, Jojo
    Joachim Schmitz, Sep 2, 2008
    #6
  7. arnuld

    Guest

    On Sep 2, 7:31 pm, Richard Heathfield <> wrote:
    > Joachim Schmitz said:
    >
    > > wrote:
    > >> On Sep 2, 10:50 am, arnuld <> wrote:
    > >>> WANTED: Even if I do Ctrl-C in the middle of fgets(), fwrite()
    > >>> should write the previously entered data to a file (except if I hit
    > >>> the file-size limit)

    >
    > >>> PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does
    > >>> not write the data to the file.

    >
    > >> ^C typically kills the process. It's not possible to do what you want.

    >
    > > ^C typically (in UNIX) sends a SIGINT, which you could catch or even
    > > ignor. But that would be off topic here...

    >
    > Why? SIGINT is a standard signal. See 4.7 of C89 or 7.14 of C99.


    SIGINT is. What ^C does (or ^C itself) is not standard though. (not
    even in POSIX)
    , Sep 2, 2008
    #7
  8. On Tue, 02 Sep 2008 14:18:09 -0700, vippstar wrote:
    > On Sep 2, 7:31 pm, Richard Heathfield <> wrote:
    >> Joachim Schmitz said:
    >> > ^C typically (in UNIX) sends a SIGINT, which you could catch or even
    >> > ignor. But that would be off topic here...

    >>
    >> Why? SIGINT is a standard signal. See 4.7 of C89 or 7.14 of C99.

    >
    > SIGINT is.


    True, but it's worth pointing out that in ISO C, there is significantly
    less that you are allowed to do in the signal handler.

    > What ^C does (or ^C itself) is not standard though. (not even
    > in POSIX)


    <OT> That depends on what you mean. What ^C does is specified by POSIX,
    but whether it is triggered by ^C is not. </OT>
    Harald van Dijk, Sep 2, 2008
    #8
  9. arnuld

    Richard Bos Guest

    Jack Klein <> wrote:

    > On Tue, 02 Sep 2008 16:31:48 +0000, Richard Heathfield
    > <> wrote in comp.lang.c:
    >
    > > Joachim Schmitz said:
    > >
    > > > wrote:
    > > >> On Sep 2, 10:50 am, arnuld <> wrote:
    > > >>> PROBLEM: If I do a Ctrl-C in the middle of fgets(). fwrite() does
    > > >>> not write the data to the file.
    > > >>
    > > >> ^C typically kills the process. It's not possible to do what you want.
    > > >
    > > > ^C typically (in UNIX) sends a SIGINT, which you could catch or even
    > > > ignor. But that would be off topic here...

    > >
    > > Why? SIGINT is a standard signal. See 4.7 of C89 or 7.14 of C99.

    >
    > ..but catching a signal that comes from anything other than the
    > executable itself calling raise() is completely undefined.


    Where do you find that?

    # If and when the function returns, if the value of sig is SIGFPE,
    # SIGILL, SIGSEGV, or any other implementation-defined value
    # corresponding to a computational exception, the behavior is undefined;

    # If the signal occurs other than as the result of calling the abort or
    # raise function, the behavior is undefined if the signal handler refers
    # to any object with static storage duration other than by assigning a
    # value to an object declared as volatile sig_atomic_t, or the signal
    # handler calls any function in the standard library other than...

    Those are the only two mentions of UB I can find. Since SIGINT is not a
    computational but a process exception, and the handler need not assign
    to a wrong object or call a wrong function, I don't see why catching
    SIGINT (and then, say, setting a volatile sig_atomic_t which causes the
    rest of the program to write its file and then abort) should cause
    undefined behaviour.
    Note that nothing in the definition of signal() makes any demands about
    the signal coming from inside or outside the executable itself. The only
    distinction made is that between an explicit call by abort() or raise(),
    and any other calls (which could, e.g., be implicit in a FP operation,
    explicit in another, non-Standard function, or from somewhere outside
    the program).

    Richard
    Richard Bos, Sep 3, 2008
    #9
    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. Zalek Bloom
    Replies:
    2
    Views:
    741
    llewelly
    Sep 9, 2003
  2. michelle

    transfer file using recv() and fwrite()

    michelle, Jun 26, 2003, in forum: C Programming
    Replies:
    2
    Views:
    3,592
    michelle
    Jun 26, 2003
  3. Replies:
    6
    Views:
    736
    Keith Thompson
    Feb 9, 2005
  4. David Mathog
    Replies:
    13
    Views:
    1,101
    J. J. Farrell
    Nov 29, 2007
  5. Abubakar

    fwrite output is not efficient (fast) ?

    Abubakar, Oct 24, 2008, in forum: C Programming
    Replies:
    15
    Views:
    1,336
    Abubakar
    Nov 5, 2008
Loading...

Share This Page