C - gets() function implementation help

[Keith Thompson]

We had a discussion a while back about whether this is a conforming
implementation:

char *gets(char *buffer) {
fputs("Hey jerk!!", stderr);
exit(0);
return NULL;
}

Since in the general case, there is no way to guarantee buffer will
not be run, causing undefined behavior, and printing "Hey jerk" and
dying is well within the bounds of undefined behavior.

I don't remember where the group ended up on it, but that looks
perfectly okay to me.

It isn't.

The behavior of gets() is well defined as long as you don't feed it a
line too long to be stored in the buffer. A conforming implementation
may not take advantage of the permissions granted by undefined
behavior unless the undefined behavior actually occurs.

I have considered it, yes, but it doesn't seem like the OP
is at an appropriate skill level to be learning such things.

What is the "appropriate skill level" for learning that gets() is
dangerous? Or did I misunderstand you?

 

[Andrew Poelstra]

It isn't.

The behavior of gets() is well defined as long as you don't feed it a
line too long to be stored in the buffer. A conforming implementation
may not take advantage of the permissions granted by undefined
behavior unless the undefined behavior actually occurs.

The argument against that was that there is always the possibility
of I/O errors - if not a malicious user, then a corrupted file, bad
pipe or network connection, stray emfs flipping bits, etc, and the
buffer could be overrun despite one's best intentions.

What is the "appropriate skill level" for learning that gets() is
dangerous? Or did I misunderstand you?

Partially. When first learning C, it's fine to say "gets is
dangerous" or "gets is evil" and leave it at that. And given
how easy it is to replace it with fgets() and a fixed buffer
(thus turning "undefined behaviour" into "defined but probably
wrong behavior"), there's no reason not to.

Using fgets() also helps them to understand how arrays and
C strings work, what buffers are, why they have boundaries
and that said boundaries are not checked.

At that point, you can explain /why/ gets() is bad. But requiring
students to implement the function, when they are at a point where
they aren't able to slodge together

c = getc();
while(c != '\n' && c != EOF) {
*buff++ = c;
c = getc();
}

, will quite likely result in the dangers going completely over
the students' heads.

 

[Nick Keighley]

Yes, it is.

<shrug> we'll just have to agree to disagree. It must be nice in your
perfect world

 

[Richard Bos]

The argument against that was that there is always the possibility
of I/O errors - if not a malicious user, then a corrupted file, bad
pipe or network connection, stray emfs flipping bits, etc, and the
buffer could be overrun despite one's best intentions.

That's not an argument. If you start letting EMF get into the way of
defined behaviour, every single function in the Standard has UB. That's
not specific to gets() at all. In fact, if you allow EMF to have an
influence, calling _no_ function has UB, too. For example,

int main(void)
{
return 0;
}

could have a padding bit in the 0 flipped by EMF and crash on trying to
return a trap value. And not a single gets() call in sight.

Partially. When first learning C, it's fine to say "gets is
dangerous" or "gets is evil" and leave it at that. And given
how easy it is to replace it with fgets() and a fixed buffer
(thus turning "undefined behaviour" into "defined but probably
wrong behavior"), there's no reason not to.

At that point, you can explain /why/ gets() is bad. But requiring
students to implement the function, when they are at a point where
they aren't able to slodge together

I would go further and say that once they _are_ able to understand the
danger, there is no longer any use in implementing gets(). So either
implementing gets() is a bad exercise because it is dangerous for
low-level students, or it is a bad exercise because it is useless for
higher(FSVO)-level students, or it is a bad exercise for both reasons
for mid-level students; it is _never_ a good exercise.

Richard

 

[Richard Bos]

Yes, it is.

<shrug> we'll just have to agree to disagree. It must be nice in your
perfect world[/QUOTE]

It's not a matter of perfection, it's a matter of getting even the
basics wrong. A teacher who thinks that implementing gets() is a good
exercise simply isn't qualified to teach programming. It's like a
driving instructor asking his pupils to devise a safe way of running a
red light. At that point, nothing else he teaches can be trusted.

Richard

 

[Alexander Bartolich]

[...]
It's not a matter of perfection, it's a matter of getting even the
basics wrong. A teacher who thinks that implementing gets() is a good
exercise simply isn't qualified to teach programming. It's like a
driving instructor asking his pupils to devise a safe way of running a
red light. At that point, nothing else he teaches can be trusted.

Your analogy fails badly.

There are people who need to know a safe way of running a red light:
policemen, firefighters, ambulance drivers.

And then the world of bits is completely unlike the world of molecules.
In a virtual environment you have the possibility to repeat missions
until you succeed, you can undo moves back to the point of safety, and
you can experiment with the insane. Flight simulators are routinely used
to train pilots on how to crash land.

In an ideal world teachers would not just let their students implement
a broken design like gets(). They would also teach them how to write
an exploit to attack their own program.

--

 

[burton.samograd]

<shrug> we'll just have to agree to disagree. It must be nice in your
perfect world

It's not like they didn't provide fgets to help with the situation. I
have always wondered why they forgot that second parameter though.

 

[Richard Bos]

[...]
It's not a matter of perfection, it's a matter of getting even the
basics wrong. A teacher who thinks that implementing gets() is a good
exercise simply isn't qualified to teach programming. It's like a
driving instructor asking his pupils to devise a safe way of running a
red light. At that point, nothing else he teaches can be trusted.

Your analogy fails badly.

There are people who need to know a safe way of running a red light:
policemen, firefighters, ambulance drivers.

My analogy doesn't fail at all, since there are also people who need to
write an implementation of gets(): authors of a C implementation. But
just as a beginning driver should not learn to pretend he is behind the
wheel of an ambulance (lest he find himself in the back of one), a
beginning programmer should not pretend to write an implementation (lest
the UB format his drive and he has to install anew).

Richard