Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > fwrite() does not write data to file

Reply
Thread Tools

fwrite() does not write data to file

 
 
arnuld
Guest
Posts: n/a
 
      09-02-2008
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

 
Reply With Quote
 
 
 
 
vippstar@gmail.com
Guest
Posts: n/a
 
      09-02-2008
On Sep 2, 10:50 am, arnuld <(E-Mail Removed)> 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>
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-02-2008
arnuld <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
arnuld
Guest
Posts: n/a
 
      09-02-2008
> 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

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-02-2008
(E-Mail Removed) wrote:
> On Sep 2, 10:50 am, arnuld <(E-Mail Removed)> 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


 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-02-2008
Richard Heathfield wrote:
> Joachim Schmitz said:
>
>> (E-Mail Removed) wrote:
>>> On Sep 2, 10:50 am, arnuld <(E-Mail Removed)> 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


 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      09-02-2008
On Sep 2, 7:31 pm, Richard Heathfield <(E-Mail Removed)> wrote:
> Joachim Schmitz said:
>
> > (E-Mail Removed) wrote:
> >> On Sep 2, 10:50 am, arnuld <(E-Mail Removed)> 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)
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-02-2008
On Tue, 02 Sep 2008 14:18:09 -0700, vippstar wrote:
> On Sep 2, 7:31 pm, Richard Heathfield <(E-Mail Removed)> 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>
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      09-03-2008
Jack Klein <(E-Mail Removed)> wrote:

> On Tue, 02 Sep 2008 16:31:48 +0000, Richard Heathfield
> <(E-Mail Removed)> wrote in comp.lang.c:
>
> > Joachim Schmitz said:
> >
> > > (E-Mail Removed) wrote:
> > >> On Sep 2, 10:50 am, arnuld <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to stream or write data into a tar.gz file as if the data werefrom files? bwv549 Ruby 12 10-06-2008 02:01 PM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net 2 07-29-2008 09:50 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net Building Controls 0 07-29-2008 01:37 AM
how to encrypt a C data and write a bin file and read a bin at run time and decrypt C data sweety C Programming 9 02-07-2006 05:28 PM
Why does the write method take a character pointer to the object one wishes to write? AMT2K5 C++ 3 12-10-2005 07:05 PM



Advertisments