fwrite() does not write data to file

[arnuld]

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 ?

 

[vippstar]

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>

 

[Keith Thompson]

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

 

[arnuld]

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

 

[Joachim Schmitz]

^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]

Joachim Schmitz said:


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

 

[vippstar]

Joachim Schmitz said:



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)

 

[Harald van Dijk]

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>

 

[Richard Bos]

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