Difference between fgets and gets

[pavunkumar]

Dear Friend

Can you explained what is difference between fgets
() and gets()
But , I Know the basic difference m gets will get the string from the
stdin
and fgets() will get the string from the file But, I want know , is
there main difference
other than above things

Advance Thanks

 

[user923005]

Dear Friend

                    Can you explained what is difference between fgets
() and gets()
But , I Know the basic difference m gets will get the string from the
stdin
and fgets() will get the string from the file  But, I want know , is
there main difference
other than above things

The most important difference is that fgets() knows how big the string
is and gets() does not. That means it is nearly impossible to write
safe code using gets() so don't do it.

 

[qarnos]

That means it is nearly impossible to write
safe code using gets() so don't do it.

*nearly*?

 

[Keith Thompson]

*nearly*?

Yes. If your program runs only in an environment in which you have
complete control over what it will see on its standard input, then you
can use gets() without fear of a buffer overrun. (But I still
wouldn't use it.)

 

[Guest]

The most important difference is that fgets() knows how big the string
is and gets() does not.  That means it is nearly impossible to write
safe code using gets() so don't do it.

don't write safe code with gets()?

 

[jfbode1029]

Dear Friend

                    Can you explained what is difference between fgets
() and gets()
But , I Know the basic difference m gets will get the string from the
stdin
and fgets() will get the string from the file  But, I want know , is
there main difference
other than above things

Advance Thanks

Two main differences:

1. fgets() allows you to specify the maximum number of characters to
read from the stream; gets() does not. If the input stream contains
more characters than the target buffer is sized to hold, gets() will
happily write those extra characters to the memory beyond the end of
the buffer, potentially clobbering something important. Numerous
worms and viruses exploit such buffer overruns to propagate
themselves. Because of this, use of gets() is *very strongly*
discouraged.

2. If input is terminated by a newline character, fgets() will store
the trailing newline in the target buffer if there is enough room.
gets() will not store the trailing newline in the buffer.

 

[Harald van Dijk]

Yes. If your program runs only in an environment in which you have
complete control over what it will see on its standard input, then you
can use gets() without fear of a buffer overrun.

Or more simply, just to prove it's possible to use it safely, once you've
read all input and feof(stdin) is true, you can call gets() all you want.

If your implementation conforms to the C standard, that is. Mine (at
least the one I'm using now) doesn't.

(But I still wouldn't use it.)

Nor would I.

 

[Richard Bos]

*nearly*?

Yes. It's possible if you have perfect typing fingers, _and_ are allowed
to use bondage gear on your colleagues (or housemates). Otherwise, no.

Richard

 

[user923005]

Yes. It's possible if you have perfect typing fingers, _and_ are allowed
to use bondage gear on your colleagues (or housemates). Otherwise, no.

I was referring to this (hypothetical and iffy case):
======================================================
Newsgroups: comp.lang.c, comp.programming
From: (e-mail address removed) (Dan Pop)
Date: 21 Nov 2003 17:05:21 GMT
Local: Fri, Nov 21 2003 9:05 am
Subject: Re: Any experience with "The Last One"?
Reply to author | Forward | Print | Individual message | Show original
| Report this message | Find messages by this author

Richard Heathfield wrote:

I know what's scary about gets(), but I don't quite see what's
scary about strcpy(),...

Same thing as gets().

char oops [2];
strcpy (oops, "Hello, this is a test of strcpy() safety!");

...when used properly.

Ah, well, that changes things. (-: Hasn't Dan Pop argued that
gets() is just fine when used properly?[1] (Granted, the places
where that's possible are highly limited, but if we're going to
"use properly", we should consider thusly in both cases, yes?)

The difference is that one can be used properly in a portable manner,
while the other cannot. Big difference!

Hey, keep us in the mix! Just because it's C doesn't mean we
can't talk about it here, too!!

[1] e.g. controlled machine output to machine input where line
lengths are fully known and controlled.

Nope, this has never been my argument. I was merely arguing the case
of input from console, where the length of an input line is limited
by
the execution environment. A program can force its stdin to be
connected
to the console, via a freopen call, so stdin redirection is not an
issue
in my "safe" gets() scenario. The weak points of this scenario are
that
the redirection cannot be done portably, even if freopen is a
standard
library function and that there may be execution environments that do
not
limit the length of a console input line.

Dan

 

[CBFalconer]

The most important difference is that fgets() knows how big the
string is and gets() does not. That means it is nearly impossible
to write safe code using gets() so don't do it.

s/nearly/totally/

In addition it has been publicly announced that the next C standard
will mark gets as obsolescent.

If you want the ease of supplying function parameters of gets, I
recommend ggets. ggets is written in standard C, thus is totally
portable, and all you supply it is the address of a char* pointer.
The penalty is that you have to dispose of that pointers data space
after the call (unless you want to preserve that line for longer)
by using free. It is accompanied by fggets, which is identical but
allows you to specify the input file. See:

<http://cbfalconer.home.att.net/download/ggets.zip>

 

[Richard]

If you want the ease of supplying function parameters of gets, I
recommend ggets. ggets is written in standard C, thus is totally
portable, and all you supply it is the address of a char* pointer.
The penalty is that you have to dispose of that pointers data space
after the call (unless you want to preserve that line for longer)
by using free. It is accompanied by fggets, which is identical but
allows you to specify the input file. See:

I've never in my programming life seen someone talk up such a
trifle. Reusable snippets are one thing, but talking up a tiny
I/O + realloc() wrapper as if it's a finished product in itself
and the first of its kind is an entirely different thing. Next
Chucky will be shipping off his ggets() as a .deb package.

[SCENE: SOPHOMORE COMPUTER SCIENCE CLASS]

PROFESSOR: Last week's homework was writing a line-reading
function. I've had a chance to look over the submissions,
and they're all pretty good. This week your project
will be writing a base64 decoder, after we've looked
at -- oh, just a moment, we have a special guest with
us today...

CHUCK FALCONER: Hello, I'm Chuck Falconer. Thank you.
Thank you, people. Thank you. OK, people, thank
you. If I may... IF I MAY... yes, thank you. OK,
yes. Please, thank you. Thank you very much. I'm
honored. Thank you. Can I have some silence please?
I appreciate... yes. Thank you. You're all kind.

PROFESSOR: Sir, if I may say so, the class has been silent
since you walked in the room.


Yours,
Han from China

LOL. Very, very good.

His ggets is indeed a pivot of modern CS development ....


<still laughing heavily>

 

[Flash Gordon]

Oh the deep evil of size_t.

No, just Richard Heathfield making a mistake. It does happen
occasionally. I would have said use 0 to indicate no limit, since it is
not very often you want to read a line of less than 0 bytes (remembering
you need space for the null termination).

 

[Flash Gordon]

No, just Richard Heathfield making a mistake. It does happen
occasionally. I would have said use 0 to indicate no limit, since it is
not very often you want to read a line of less than 0 bytes (remembering
you need space for the null termination).

Of course, the maximum value of size_t is fine as well, so he did not
make a mistake.

 

[Richard Tobin]

Just let the programmer pass the maximum length he's prepared to
accept, as a size_t. If he passes -1, fine, he doesn't care.
^^^^^

[/QUOTE]

Oh the deep evil of size_t.

Are you objecting to the fact that -1 isn't an out-of-range value for
size_t? In this case, it works well, because "don't care" is the same
as "allow the maximum possible", and (size_t)-1 is the maximum
possible.

(Ignoring the endlessly discussed possibility of objects to big
for a size_t.)

-- Richard

 

[Flash Gordon]

Flash Gordon said:


What mistake?


Aye, and more often than it should - but I don't think it happened
on this occasion.

See my reply to myself. Mind you, you are not talking about passing -1
to the function since it actually receives (size_t)-1 instead ;-)
There, does that wriggle it in to me being correct ;-)

I dislike using an in-band value in that way. It's counter-intuitive
(to me, at least) to expect a 0-byte limit to become "no limit".

Maybe it is my background, but I am quite used to things like 0 for
unlimited.

Okay, I realise that -1 doesn't seem intuitive either on the face
of it, but to a C programmer a size_t value of -1 has, or ought to
have, an obvious C meaning - i.e. "the largest possible value of
the unsigned type", which is the /effective/ limit anyway.

Agreed. Had I been awake...

And in any case I've #defined it with a sensible name.

Yes, well, of course one should provide a suitable name

 

[Keith Thompson]

But you want to represent an amount of memory that means "I don't
care". Note this is entirely legitimate. If you are asked "how many
sugars do you take in your tea?", "zero", "one", "two", and "I don't
know (my wife always makes it)", or "I don't care" (I genuinely don't,
though I say "one" when asked because it seems more polite, and have
none when I make tea for myself) are all reasonable answers.

Now the problem is that, being unsigned, size_t has to take a value,
or you get the stupidity of assigning -1 to a natural integer. In this
case "as big as possible" is the same as "don't care", so SIZE_MAX
solves that particular problem, but, as you say, the inventors of
size_t forgot to include it. So we are left with a choice between
somethign stupid or something non-portable, all to solve the problem
of strings potentially being bigger than half the address space of the
machine.

The fact that -1 is implicitly converted to the maximum value of
size_t (now called SIZE_MAX) is a fundamental result of the way
unsigned integers work in C. It's a little bit counterintuitive
mathematically, but any C programmer needs to be aware of it, and
taking advantage of it is a perfectly legitimate programming
technique. Your calling it "stupid" doesn't make it so; it's no more
stupid than the fact that 1.0/3.0*3.0 != 1.0.

 

[Mark Wooding]

C is a modern programming language? When did that happen?

Fairly recently, by definition! ;-)

Passing (size_t)-1 seems perfectly reasonable to me, by the way.

-- [mdw]

 

[Richard Bos]

This is total and utter bullshit.

In any controlled environment where the communication is marshalled then
the use of gets() is totally safe.

Similarly, in any controlled environment where you're completely clad in
Kevlar, Russian roulette is totally safe.

The problem, in both cases, is finding that environment.

It's like saying memcpy is unsafe if you pass it the wrong length.

On the contrary. If you pass the wrong length to memcpy(), that is
entirely _your_ fault. You know (or should know) the size of the block
your pointers point at, so you are able to pass the right length. With
gets(), not only are you not able to pass _any_ length, let alone the
right one - which would merely make it as unsafe as strcpy(), that is,
unsafe in incompetent hands - but you are not reliably able to find out
what the right length _is_, which makes it unsafe even in competent
hands, and even more so in hands which judge themselves competent enough
to use it safely.

Do try to drop this bone.

Do stop howling at the moon, doggy-boy.

Richard

 

[Guest]

This is total and utter <expletive indicating nonsense>.

In any controlled environment where the communication is marshalled then
the use of gets() is totally safe.

whilst I don't think Chuck added much with his comment I'd rather
newbie programmers walked around with the idea in their heads "gets is
impossible
to use safely" than the potentially dangerous "gets is nearly
impossible to
use safely".

I'm curious, have you ever written a program that ran in such a
"marshalled"
environment that used gets() safely. And why didn't you use fgets()?

Do you consider ranting at Chuck to be a good use for your time?
And your blood pressure?

 

[Richard]

whilst I don't think Chuck added much with his comment I'd rather
newbie programmers walked around with the idea in their heads "gets is
impossible
to use safely" than the potentially dangerous "gets is nearly
impossible to
use safely".

Like Chuck with his ggets you and your "gets" is like a dog with a bone.

gets is PERFECTLY safe to use by a programmer who knows its limitations
and uses it in a controlled environment.

We realise how proud you are of knowing it can overflow but so can any
goddam piece of C you write using pointers without control.

Not in control of the input? Don't use gets. Simple.

I'm curious, have you ever written a program that ran in such a
"marshalled"
environment that used gets() safely. And why didn't you use fgets()?

I have. Lots of times. generally in older code I have been asked to
spruce up / profile etc. Would I advocate its use? No. Not really. Would
I blow my fuse if I saw it in use where data was fed into it in packets
of a known length? Of course not.

Do you consider ranting at Chuck to be a good use for your time?
And your blood pressure?

My blood pressure is fine. Is my laughter wrinkles that are starting to
stretch reading this high and mighty holier than thou nonsense time
after f*cking time here.