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

On Sep 2, 10:50 am, arnuld <sunr...@invalid.addresswrote:^C typically kills the process. It's not possible to do what you want.

<snip>

arnuld <sunrise@invalid.addresswrites:
[...]fflush().

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

arnuld said:
Implementations are permitted to buffer streams, in which case an arbitrary
program termination may result in data in the buffer not being written to
the associated file.

To ensure (as far as possible, anyway) that data sent to fwrite is written
to the file, call fflush after fwrite:

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.

If you mean data processed by /this/ fgets call, the one that you've just
interrupted, it isn't possible to do that in standard C - not even if you
mess with signal-handling - since there is no obligation on fgets to have
placed any data at all into your buffer at the point of interruption. It
only has to have done so by the time it returns, and it can't return (in
the normal sense) if you interrupt it.

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

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

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

vippstar@gmail.com wrote:^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 said:
Why? SIGINT is a standard signal. See 4.7 of C89 or 7.14 of C99.

--
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 wrote:Well, because I thought it to be POSIX.

Thanks for the correction.

Bye, Jojo

On Sep 2, 7:31 pm, Richard Heathfield <r...@see.sig.invalidwrote:SIGINT is. What ^C does (or ^C itself) is not standard though. (not
even in POSIX)

On Tue, 02 Sep 2008 14:18:09 -0700, vippstar wrote: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.
<OTThat depends on what you mean. What ^C does is specified by POSIX,
but whether it is triggered by ^C is not. </OT>

vippstar@gmail.com said:
True enough, but working out what the OP meant by ^C is hardly rocket
science.

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

On Tue, 02 Sep 2008 16:31:48 +0000, Richard Heathfield
<rjh@see.sig.invalidwrote in comp.lang.c:
...but catching a signal that comes from anything other than the
executable itself calling raise() is completely undefined.

So any discussion of how to generate a SIGINT, other than calling
raise(), or what happens when catching a SIGINT that did was not
generated by a call to raise(), is indeed OT here.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack Klein <jackklein@spamcop.netwrote:
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