reading a file in reverse order (bootom-top)

[sahukar praveen]

Hello,

I have a question.

I try to print a ascii file in reverse order( bottom-top). Here is the logic.

1. Go to the botton of the file fseek(). move one character back to avoid the EOF.
2. From here read a character, print it, move the file pointer (FILE*) to 2 steps back (using fseek(fp, -2, SEEK_CUR)) to read the previous character.

This seems to be ok if the file has a single line (i.e. no new line character). The above logic fails if it encounters a new line character and gets into an infinite loop priting a series of new-line character.

To fix this I checked for the character read and if it is new-line character, I move the file pointer by 3 steps (fseek(fp, -3, SEEK_CUR)) and now the logic works fine.

Can anyone please explain me why a this special consideration for a new-line character.

Many Thanks in advance.

Thanks
Praveen

[CBFalconer]

sahukar praveen wrote:

Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable

Please do not post html or attachments in c.l.c.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[John Bode]

"sahukar praveen" <sa************@yahoo.co.in> wrote in message news:<3f******@usenet01.boi.hp.com>...

Hello,

I have a question.

I try to print a ascii file in reverse order( bottom-top). Here is the
logic.

1. Go to the botton of the file fseek(). move one character back to
avoid the EOF.
2. From here read a character, print it, move the file pointer (FILE*)
to 2 steps back (using fseek(fp, -2, SEEK CUR)) to read the previous
character.

This seems to be ok if the file has a single line (i.e. no new line
character). The above logic fails if it encounters a new line character
and gets into an infinite loop priting a series of new-line character.

To fix this I checked for the character read and if it is new-line
character, I move the file pointer by 3 steps (fseek(fp, -3, SEEK CUR))
and now the logic works fine.

Can anyone please explain me why a this special consideration for a
new-line character.

Many Thanks in advance.

Thanks
Praveen
--

Some platforms represent a newline with a carriage return and line
feed pair, rather than a single newline character, which is why you
need to back up three characters instead of two.

Instead of reading a single character at a time, you might want to
grab a chunk of characters into a buffer, then print from that buffer.
For one thing, it reduces the number of calls to fseek() (which may
be a fairly expensive operation), and you can just skip over the
characters you don't want to print.

[Mark McIntyre]

On Tue, 25 Nov 2003 16:38:48 +0530, in comp.lang.c , "sahukar praveen"
<sa************@yahoo.co.in> wrote:

Hello,

I have a question.

I try to print a ascii file in reverse order( bottom-top).

A quicker way if you have enugh memory would be to malloc a block of
memory you think is large enough for the entire file, fread() the file
into it, go to the last byte and walk backwards through the block.
PLatform specific extensions would help you find how much memory you
needed.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Debashish Chakravarty]

Mark McIntyre <ma**********@spamcop.net> wrote in message :

A quicker way if you have enugh memory would be to malloc a block of
memory you think is large enough for the entire file, fread() the file
into it, go to the last byte and walk backwards through the block.
PLatform specific extensions would help you find how much memory you
needed.

The solution I could think of printing the file in reverse order
without attempting to know the size of the file was a recursive one.
But I think this solution might choke on large files. This recursive
solution is equivalent to pushing characters on a stack and then
popping them, I think reading more than one character at a time would
led to faster code.

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

/*print the characters of the file in reverse order*/
void rev_file_c(FILE *fp)
{
int c;
c=fgetc(fp);
if(c==EOF) return;
rev_file_c(fp);
putchar(c);
}

#define MAX_LINE_SIZE 4096
/*print the lines of the file in reverse order*/
void rev_file_lin(FILE *fp)
{
char buf[MAX_LINE_SIZE];
char *s;
s=fgets(buf,sizeof buf,fp);
if(NULL==s)
{
if(ferror(fp))
{
perror(NULL);
exit(EXIT_FAILURE);
}
else return;
}
rev_file_lin(fp);
fputs(buf,stdout);
}

int
main(void)
{
FILE *fp;
fp=fopen("c:\\temp\\rev_file.c","r");
if(NULL == fp)
{
perror(NULL);
return 1;
}
rev_file_c(fp);
fclose(fp);
return 0;
}

--------
Jai Hind!
Vande Mataram.

[CBFalconer]

Debashish Chakravarty wrote:

Mark McIntyre <ma**********@spamcop.net> wrote in message :

A quicker way if you have enugh memory would be to malloc a block of
memory you think is large enough for the entire file, fread() the file
into it, go to the last byte and walk backwards through the block.
PLatform specific extensions would help you find how much memory you
needed.

The solution I could think of printing the file in reverse order
without attempting to know the size of the file was a recursive one.
But I think this solution might choke on large files. This recursive
solution is equivalent to pushing characters on a stack and then
popping them, I think reading more than one character at a time would
led to faster code.

Try this one. I would write a few things differently today, and
there is an insect in revstring, which won't get triggered here.

/* Routines to reverse a file, char by char. */
/* by C.B. Falconer, 19 Dec. 2001 */
/* Released to public domain. Attribution appreciated */

/* Known bugs - A file without an initial empty line */
/* will have one added. */

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

#define MAXLN 256

typedef struct line {
char *ln;
struct line *next;
} line, *lineptr;

/* ======================================= */
/* reverse string in place. Return length */
size_t revstring(char *string)
{
char *last, temp;
size_t lgh;

lgh = strlen(string);
last = string + lgh; /* points to '\0' */
while (last-- > string) {
temp = *string; *string++ = *last; *last = temp;
}
return lgh;
} /* revstring */

/* ========================= */
/* Reverse file, end to end */
int main(void)
{
char buffer[MAXLN];
lineptr p, last;
size_t lgh;

p = last = NULL;
while (fgets(buffer, MAXLN, stdin)) {
lgh = revstring(buffer);
if (p = malloc(sizeof (line))) {
p->next = last;
if (p->ln = malloc(lgh + 1)) {
strcpy(p->ln, buffer);
last = p;
}
else {
free(p);
break;
}
}
else break;
}
p = NULL;
while (last) {
free(p);
fputs(last->ln, stdout);
p = last;
last = last->next;
}
if (p && ('\n' != p->ln[strlen(p->ln) - 1]))
fputc('\n', stdout);
free(p);
return 0;
} /* main */

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Mantorok Redgormor]

CBFalconer <cb********@yahoo.com> wrote in message news:<3F***************@yahoo.com>...

Debashish Chakravarty wrote:

Mark McIntyre <ma**********@spamcop.net> wrote in message :

A quicker way if you have enugh memory would be to malloc a block of
memory you think is large enough for the entire file, fread() the file
into it, go to the last byte and walk backwards through the block.
PLatform specific extensions would help you find how much memory you
needed.

The solution I could think of printing the file in reverse order
without attempting to know the size of the file was a recursive one.
But I think this solution might choke on large files. This recursive
solution is equivalent to pushing characters on a stack and then
popping them, I think reading more than one character at a time would
led to faster code.

Try this one. I would write a few things differently today, and
there is an insect in revstring, which won't get triggered here.

/* Routines to reverse a file, char by char. */
/* by C.B. Falconer, 19 Dec. 2001 */
/* Released to public domain. Attribution appreciated */

/* Known bugs - A file without an initial empty line */
/* will have one added. */

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

#define MAXLN 256

typedef struct line {
char *ln;
struct line *next;
} line, *lineptr;

/* ======================================= */
/* reverse string in place. Return length */
size_t revstring(char *string)
{
char *last, temp;
size_t lgh;

lgh = strlen(string);
last = string + lgh; /* points to '\0' */
while (last-- > string) {
temp = *string; *string++ = *last; *last = temp;
}
return lgh;
} /* revstring */

/* ========================= */
/* Reverse file, end to end */
int main(void)
{
char buffer[MAXLN];
lineptr p, last;
size_t lgh;

p = last = NULL;
while (fgets(buffer, MAXLN, stdin)) {
lgh = revstring(buffer);
if (p = malloc(sizeof (line))) {
p->next = last;
if (p->ln = malloc(lgh + 1)) {
strcpy(p->ln, buffer);
last = p;
}
else {
free(p);
break;
}
}
else break;
}
p = NULL;
while (last) {
free(p);
fputs(last->ln, stdout);
p = last;
last = last->next;
}
if (p && ('\n' != p->ln[strlen(p->ln) - 1]))
fputc('\n', stdout);
free(p);
return 0;
} /* main */

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

static unsigned int byte_count(FILE *);
static void reverse_file(char *, unsigned int);

int main(int argc, char **argv)
{
char *ptr;
unsigned int size;
FILE *fp;

if(argc < 2)
printf("%s <file>\n", argv[0]);
if(!(fp = fopen(argv[1], "r")))
return EXIT_FAILURE;

size = byte_count(fp);

if(!(ptr = malloc(size+1)))
return EXIT_FAILURE;

ptr[size] = '\0';

fread(ptr, size, sizeof(char), fp);

fclose(fp);

reverse_file(ptr, size);

return EXIT_SUCCESS;
}
static unsigned int byte_count(FILE *fp)
{
int c;
unsigned int count = 0;

while((c = fgetc(fp)) != EOF)
++count;

rewind(fp);

return count;
}

static void reverse_file(char *base, unsigned int size)
{
char *end = &base[size-1];

if(*end == '\n') {
*end = '\0';
--end;
}

for( ; end >= base; --end)
if(*end == '\n') {
*end = '\0';
printf("%s\n", end+1);
}

printf("%s\n", base);

free(base);
}

I think my version might outperform yours.
fgets is kind of slow on large files.

--
nethlek

[CBFalconer]

Mantorok Redgormor wrote:

.... snip ...
I think my version might outperform yours.
fgets is kind of slow on large files.

I believe it doesn't do the same thing. In addition I doubt that
reading a file twice can be faster than reading it once.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Villy Kruse]

On Thu, 27 Nov 2003 08:07:47 GMT,
CBFalconer <cb********@yahoo.com> wrote:

Mantorok Redgormor wrote:

... snip ...

I think my version might outperform yours.
fgets is kind of slow on large files.

I believe it doesn't do the same thing. In addition I doubt that
reading a file twice can be faster than reading it once.

Not to mention that reading the entire contents of a huge file into memory
is not exactly the best thing to do. But of course having gigabytes of
real memory available will surely help.
Villy

[CBFalconer]

Villy Kruse wrote:

CBFalconer <cb********@yahoo.com> wrote:

Mantorok Redgormor wrote:

... snip ...

I think my version might outperform yours.
fgets is kind of slow on large files.

I believe it doesn't do the same thing. In addition I doubt
that reading a file twice can be faster than reading it once.

Not to mention that reading the entire contents of a huge file
into memory is not exactly the best thing to do. But of course
having gigabytes of real memory available will surely help.

Inasmuch as my version also reads everything into memory, I didn't
consider that a valid objection :-) However the response to
memory allocation failure is also different.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Joe Wright]

CBFalconer wrote:

Villy Kruse wrote:

CBFalconer <cb********@yahoo.com> wrote:

Mantorok Redgormor wrote:
>
... snip ...
>
> I think my version might outperform yours.
> fgets is kind of slow on large files.

I believe it doesn't do the same thing. In addition I doubt
that reading a file twice can be faster than reading it once.

Not to mention that reading the entire contents of a huge file
into memory is not exactly the best thing to do. But of course
having gigabytes of real memory available will surely help.

Inasmuch as my version also reads everything into memory, I didn't
consider that a valid objection :-) However the response to
memory allocation failure is also different.

Sorry I'm late. Here's mine. It reads the file twice but only one line
at a time is ever in memory.

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

#define MAX(a,b) ((a) > (b) ? (a) : (b))

int main(int argc, char *argv[]) {
FILE *in = stdin, *out = stdout;
int ch, i, lines = 0, len = 0, max = 0;
long *linpa;
char *buff;
if (argc > 1)
if ((in = fopen(argv[1], "r")) == NULL)
fprintf(stderr, "Can't open %s\n", argv[1]),
exit(EXIT_FAILURE);

if (argc > 2)
if ((out = fopen(argv[2], "w")) == NULL)
fprintf(stderr, "Can't make %s\n", argv[2]),
exit(EXIT_FAILURE);

while ((ch = fgetc(in)) != EOF) {
++len;
if (ch == '\n') {
++lines;
max = MAX(len, max);
len = 0;
}
}

fprintf(stderr, "There are %d lines in %s\n", lines, argv[1]);
fprintf(stderr, "The longest of which is %d characters\n", max);

rewind(in);
buff = malloc(max + 1);
linpa = malloc((lines + 1) * sizeof *linpa);
if (buff == NULL || linpa == NULL)
fprintf(stderr, "Can't allocate memory\n"), exit(EXIT_FAILURE);
i = 0;
linpa[i] = 0;
while ((ch = fgetc(in)) != EOF)
if (ch == '\n')
linpa[++i] = ftell(in);

for (i = lines - 1; i >= 0; --i) {
fseek(in, linpa[i], SEEK_SET);
fgets(buff, max+1, in);
fputs(buff, out);
}
return EXIT_SUCCESS;
}

--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Joe Wright wrote:

CBFalconer wrote:

Villy Kruse wrote:

CBFalconer <cb********@yahoo.com> wrote:
> Mantorok Redgormor wrote:
>>
>... snip ...
>>
>> I think my version might outperform yours.
>> fgets is kind of slow on large files.
>
> I believe it doesn't do the same thing. In addition I doubt
> that reading a file twice can be faster than reading it once.

Not to mention that reading the entire contents of a huge file
into memory is not exactly the best thing to do. But of course
having gigabytes of real memory available will surely help.

Inasmuch as my version also reads everything into memory, I didn't
consider that a valid objection :-) However the response to
memory allocation failure is also different.

Sorry I'm late. Here's mine. It reads the file twice but only one line
at a time is ever in memory.

It still doesn't do the same thing :-) (besides reading the file
twice). Note that my version reversed the file, not just the line
order. I.e. every byte was reversed in order.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Joe Wright]

CBFalconer wrote:

Joe Wright wrote:

CBFalconer wrote:

Villy Kruse wrote:
> CBFalconer <cb********@yahoo.com> wrote:
> > Mantorok Redgormor wrote:
> >>
> >... snip ...
> >>
> >> I think my version might outperform yours.
> >> fgets is kind of slow on large files.
> >
> > I believe it doesn't do the same thing. In addition I doubt
> > that reading a file twice can be faster than reading it once.
>
> Not to mention that reading the entire contents of a huge file
> into memory is not exactly the best thing to do. But of course
> having gigabytes of real memory available will surely help.

Inasmuch as my version also reads everything into memory, I didn't
consider that a valid objection :-) However the response to
memory allocation failure is also different.

Sorry I'm late. Here's mine. It reads the file twice but only one line
at a time is ever in memory.

It still doesn't do the same thing :-) (besides reading the file
twice). Note that my version reversed the file, not just the line
order. I.e. every byte was reversed in order.

Boo. That's not so hard at all.

.....

for (i = lines - 1; i >= 0; --i) {
fseek(in, linpa[i], SEEK_SET);
fgets(buff, max+1, in);
rev(buff);
fputs(buff, out);
}
return EXIT_SUCCESS;
}

void rev(char *src) {
char *des = src;
int tmp;
while (*des) ++des;
while (--des > src) {
tmp = *des;
*des = *src;
*src++ = tmp;
}
}

And mine is shorter than yours. (That really sounds wierd. Sorry.) :=)
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Jeff Rodriguez]

sahukar praveen wrote:

Hello,

I have a question.

I try to print a ascii file in reverse order( bottom-top). Here is the
logic.

1. Go to the botton of the file fseek(). move one character back to
avoid the EOF.
2. From here read a character, print it, move the file pointer (FILE*)
to 2 steps back (using fseek(fp, -2, SEEK_CUR)) to read the previous
character.

This seems to be ok if the file has a single line (i.e. no new line
character). The above logic fails if it encounters a new line character
and gets into an infinite loop priting a series of new-line character.

To fix this I checked for the character read and if it is new-line
character, I move the file pointer by 3 steps (fseek(fp, -3, SEEK_CUR))
and now the logic works fine.

Can anyone please explain me why a this special consideration for a
new-line character.

Many Thanks in advance.

Thanks
Praveen

Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program
--snip--
/* reverse.c -- displays a file in reverse order */
#include <stdio.h>
#include <stdlib.h>
#define CNTL_Z '\032' /* eof marker in DOS text files */
#define SLEN 50
int main(void)
{
char file[SLEN];
char ch;
FILE *fp;
long count, last;

puts("Enter the name of the file to be processed:");
gets(file);
if ((fp = fopen(file,"rb")) == NULL)
{ /* read-only and binary modes */
printf("reverse can't open %s\n", file);
exit(1);
}
fseek(fp, 0L, SEEK_END); /* go to end of file */
last = ftell(fp);
for (count = 1L; count <= last; count++)
{
fseek(fp, -count, SEEK_END); /* go backward */
ch = getc(fp);
/* for DOS, works with UNIX */
if (ch != CNTL_Z && ch != '\r')
putchar(ch);
/* for Macintosh */
/* if (ch == '\r')
putchar('\n');
else
putchar(ch); */
}
putchar('\n');
fclose(fp);
return 0;
}
--snip--
This operates on the idea that your lines are no longer than 50 chars... but
that's easy to work around. This should give you the basic idea.

Jeff

[CBFalconer]

Jeff Rodriguez wrote:

.... snip ... Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program
--snip--
/* reverse.c -- displays a file in reverse order */
#include <stdio.h>
#include <stdlib.h>
#define CNTL_Z '\032' /* eof marker in DOS text files */
#define SLEN 50
int main(void)
{
char file[SLEN];
char ch;
FILE *fp;
long count, last;

puts("Enter the name of the file to be processed:");
gets(file);

^^^^
Enough said. Don't buy that book. Burn it if you have it. Also
missing any fflush.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

Jeff Rodriguez wrote:

Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program
<snip>

puts("Enter the name of the file to be processed:");
gets(file);
This is enough to condemn the book.
if ((fp = fopen(file,"rb")) == NULL)
{ /* read-only and binary modes */
printf("reverse can't open %s\n", file);
exit(1);
}
fseek(fp, 0L, SEEK_END); /* go to end of file */

If the file is binary, SEEK_END is not guaranteed to work. The Standard
says: "A binary stream need not meaningfully support fseek calls with a
whence value of SEEK_END."

<snip>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

CBFalconer wrote:

Jeff Rodriguez wrote:

puts("Enter the name of the file to be processed:");
gets(file); ^^^^
Enough said. Don't buy that book. Burn it if you have it.

Yes - MPEG optional but desirable.
Also missing any fflush.

Why would he need fflush here?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[CBFalconer]

Richard Heathfield wrote:

CBFalconer wrote:

Jeff Rodriguez wrote:

puts("Enter the name of the file to be processed:");
gets(file);

^^^^
Enough said. Don't buy that book. Burn it if you have it.

Yes - MPEG optional but desirable.

Also missing any fflush.

Why would he need fflush here?

Woops. At least it will do no harm.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Jeff Rodriguez]

Richard Heathfield wrote:

Jeff Rodriguez wrote:

Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program

<snip>

puts("Enter the name of the file to be processed:");
gets(file);

This is enough to condemn the book.

if ((fp = fopen(file,"rb")) == NULL)
{ /* read-only and binary modes */
printf("reverse can't open %s\n", file);
exit(1);
}
fseek(fp, 0L, SEEK_END); /* go to end of file */

If the file is binary, SEEK_END is not guaranteed to work. The Standard
says: "A binary stream need not meaningfully support fseek calls with a
whence value of SEEK_END."

<snip>

"This should give you the basic idea. "

This snippet came from a chapter in the book before memory management, like I
said.. the basic idea. Dump all over the book if you wish, just keep in mind
that snippet is very out context and the reason I posted it here is convey the
basic idea of how to do what the OP wanted.

Jeff

[Richard Heathfield]

Jeff Rodriguez wrote:

Richard Heathfield wrote:

Jeff Rodriguez wrote:

Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program

<snip>

puts("Enter the name of the file to be processed:");
gets(file);

This is enough to condemn the book.

if ((fp = fopen(file,"rb")) == NULL)
{ /* read-only and binary modes */
printf("reverse can't open %s\n", file);
exit(1);
}
fseek(fp, 0L, SEEK_END); /* go to end of file */

If the file is binary, SEEK_END is not guaranteed to work. The Standard
says: "A binary stream need not meaningfully support fseek calls with a
whence value of SEEK_END."

<snip>

"This should give you the basic idea. "

But it doesn't - or at least, it doesn't from the point of view of this
newsgroup.
This snippet came from a chapter in the book before memory management,
like I said.. the basic idea. Dump all over the book if you wish, just
keep in mind that snippet is very out context and the reason I posted it
here is convey the basic idea of how to do what the OP wanted.

It conveys a non-portable technique which might be appropriate in a
platform-specific newsgroup such as comp.os.msdos.programmer, but not in a
newsgroup such as this one, where we don't allow ourselves the luxury of
code that depends on non-portable tricks.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[CBFalconer]

Jeff Rodriguez wrote:

Richard Heathfield wrote:

Jeff Rodriguez wrote:

Here's a code example ripped directry from my "C Primer Plus" book:
Listing 13.5 The reverse.c Program

<snip>

puts("Enter the name of the file to be processed:");
gets(file);

This is enough to condemn the book.

<snip>

This snippet came from a chapter in the book before memory
management, like I said.. the basic idea. Dump all over the
book if you wish, just keep in mind that snippet is very out
context and the reason I posted it here is convey the basic
idea of how to do what the OP wanted.

You still fail to get the point. If you are sloppy enough, or
ignorant enough, to use gets in place of fgets, and thus inculcate
evil habits in dewey eyed newbies, your book deserves consignment
to the incinerator. At the very least the gets usage should have
been accompanied by strong warnings.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!