gets() is dead

[Flash Gordon]

Hallvard B Furuseth wrote, On 03/05/07 12:54:

I get it. I get it. What I don't get is why it's such a big deal
whether or not it gets removed from the standard. You don't need these
heavy padlocks. All you need is to not use it if you want the program
to stay in control of itself. And most of this talk about checking to
see if gets() is used is just nonsense. Sure, if someone hands you a
program and you happen to notice it uses gets(), that's reason to get
mighty suspicious. But quite likely, reading a bit of that person's
code in the program will also give you a reason to get mighty suspicious
- whether or not it is in a program which where he happens to use
gets().

The problem with gets is bad instructors and the students taught by them
in my opinion.

If we _are_ talking about helping naive users, then like I said what I'd
like to see is the addition of a safe and equally convenient function.
By all means remove gets() from the standard too, but that isn't going
to remove it from existing libraries anytime soon. So programs won't
suddenly turn safe (in that particular regared) because of it.

No, they won't. However, it will not be removed from libraries until
*after* it is removed from the standard, and it will not be removed from
the standard until *after* it has been deprecated. So it being
deprecated is a necessary first step to getting rid of it, and getting
rid of it will one day stop bad instructors from teaching students to
use it.

Well, that is my opinion.

I also think that it was stupid of the ANSI and ISO committees not to
deprecate it in the first standard. Other things which at the time were
common were deprecated in ANSI C89, so why not gets? However, that is in
the past.

Note, I am not saying the people on the committees are stupid, merely
that something they did (or did not do) was stupid, and even the best
people sometimes do stupid things.

 

[Malcolm McLean]

Malcolm McLean said:

Malcolm McLean said:

But what if you decrease machine B and C type errors by increasing
errors of type D and E? [See little black bag post elsethread].

No, thanks. I'd rather scrap the whole crappy system and write
something that works. This would involve not using any of the people
involved in writing any of the above systems, since they are clearly
no good at their job.

The example is a little bit silly [...]

Such a machine will be tested extensively and it is unlikely that such
an obvious bug would survive. But what it it were calculating potato
deliveries?

My previous answer stands.

If the customer gets two sacks instead of one then that
means someone has got to get in a van, drive there, and pick it up.
Maybe a fifty pound loss to the company. Clearly if the consequence of
a bug is only fifty pounds, it is not economic to so more than about
fifty pounds worth of testing, and if you have one good programmer and
one idiot, you put the good guy on the insulin machine which leaves
the idiot on the potato program.

The cost to the company of employing an idiot as a programmer far
exceeds fifty pounds. In fact, even if he's on UK minimum wage, the
cost to the company of employing him will exceed fifty pounds *per day*
when you take into account Employer's NI and the cost of any ancillary
benefits.

The normal method of dealing with such people, alas, is to move them
into management or marketing or, if they're astoundingly dense,
marketing management. You certainly don't let them anywhere near a
keyboard.

When idiots are the only programmers to be had, the cost of not employing
one is to close the company. The art of management, which you so despise, to
extract decent or at least profitable software from such idiots. One
technique is to sell the NHS (British state medical service) a computer
system for twelve billion pounds to store patient records which I could
knock up in a month for a couple of thousand. All you need is a web server
with some encryption over the top. This is marketing mangement at its best.

 

[Richard Heathfield]

Malcolm McLean said:

When idiots are the only programmers to be had, the cost of not
employing one is to close the company.

But idiots are not the only programmers to be had, so the question
doesn't arise.

The art of management, which you so despise,

I'm not anti-management. I'm anti-idiot. (Oh, but wait...)

(Yeah, yeah, Scott Adams said it first...)

 

[Flash Gordon]

Malcolm McLean wrote, On 05/05/07 07:29:

Malcolm McLean said:

Malcolm McLean said:

But what if you decrease machine B and C type errors by increasing
errors of type D and E? [See little black bag post elsethread].

No, thanks. I'd rather scrap the whole crappy system and write
something that works. This would involve not using any of the people
involved in writing any of the above systems, since they are clearly
no good at their job.

The example is a little bit silly [...]

Such a machine will be tested extensively and it is unlikely that such
an obvious bug would survive. But what it it were calculating potato
deliveries?

My previous answer stands.

If the customer gets two sacks instead of one then that
means someone has got to get in a van, drive there, and pick it up.
Maybe a fifty pound loss to the company. Clearly if the consequence of
a bug is only fifty pounds, it is not economic to so more than about
fifty pounds worth of testing, and if you have one good programmer and
one idiot, you put the good guy on the insulin machine which leaves
the idiot on the potato program.

The cost to the company of employing an idiot as a programmer far
exceeds fifty pounds. In fact, even if he's on UK minimum wage, the
cost to the company of employing him will exceed fifty pounds *per day*
when you take into account Employer's NI and the cost of any ancillary
benefits.

The normal method of dealing with such people, alas, is to move them
into management or marketing or, if they're astoundingly dense,
marketing management. You certainly don't let them anywhere near a
keyboard.

When idiots are the only programmers to be had, the cost of not
employing one is to close the company.

Since there are programmers to be had who are not idiots this is not a
problem.

> The art of management, which you
so despise, to extract decent or at least profitable software from such
idiots.

Obviously you know very little about management. Unfortunately a lot of
managers know very little about management, but there are some that do
know about it.

> One technique is to sell the NHS (British state medical service)
a computer system for twelve billion pounds to store patient records
which I could knock up in a month for a couple of thousand. All you need
is a web server with some encryption over the top. This is marketing
mangement at its best.

Well, you have just shown that you do not understand web servers (they
have encryption built in so you don't need to add it over the top) or
the numbers of people accessing the data which means that you need a
server farm not a simple single server, or the amount of data which
means even if you bought cheap discs the discs alone would cost more
than "a couple of thousand". There are many other requirements which are
obvious which also put up the cost of the solution. So your costs would
soon spiral or your solution would fail very quickly. Whether the
government is being ripped off is another matter, but if you think you
could solve it for a couple of thousand you are obviously not qualified
to judge. I know this because I'm now involved in some lower volume DB
stuff and the cheapest we can get the HW is far more than a couple of
thousand, and that is ignoring all the people costs of any work.

 

[Malcolm McLean]

Malcolm McLean wrote, On 05/05/07 07:29:

Malcolm McLean said:


Malcolm McLean said:

<snip>

But what if you decrease machine B and C type errors by increasing
errors of type D and E? [See little black bag post elsethread].

No, thanks. I'd rather scrap the whole crappy system and write
something that works. This would involve not using any of the people
involved in writing any of the above systems, since they are clearly
no good at their job.

The example is a little bit silly [...]

Such a machine will be tested extensively and it is unlikely that such
an obvious bug would survive. But what it it were calculating potato
deliveries?

My previous answer stands.

If the customer gets two sacks instead of one then that
means someone has got to get in a van, drive there, and pick it up.
Maybe a fifty pound loss to the company. Clearly if the consequence of
a bug is only fifty pounds, it is not economic to so more than about
fifty pounds worth of testing, and if you have one good programmer and
one idiot, you put the good guy on the insulin machine which leaves
the idiot on the potato program.

The cost to the company of employing an idiot as a programmer far
exceeds fifty pounds. In fact, even if he's on UK minimum wage, the
cost to the company of employing him will exceed fifty pounds *per day*
when you take into account Employer's NI and the cost of any ancillary
benefits.

The normal method of dealing with such people, alas, is to move them
into management or marketing or, if they're astoundingly dense,
marketing management. You certainly don't let them anywhere near a
keyboard.

When idiots are the only programmers to be had, the cost of not employing
one is to close the company.

Since there are programmers to be had who are not idiots this is not a
problem.

The art of management, which you
so despise, to extract decent or at least profitable software from such
idiots.

Obviously you know very little about management. Unfortunately a lot of
managers know very little about management, but there are some that do
know about it.

One technique is to sell the NHS (British state medical service)
a computer system for twelve billion pounds to store patient records
which I could knock up in a month for a couple of thousand. All you need
is a web server with some encryption over the top. This is marketing
mangement at its best.

Well, you have just shown that you do not understand web servers (they
have encryption built in so you don't need to add it over the top) or the
numbers of people accessing the data which means that you need a server
farm not a simple single server, or the amount of data which means even if
you bought cheap discs the discs alone would cost more than "a couple of
thousand". There are many other requirements which are obvious which also
put up the cost of the solution. So your costs would soon spiral or your
solution would fail very quickly. Whether the government is being ripped
off is another matter, but if you think you could solve it for a couple of
thousand you are obviously not qualified to judge. I know this because I'm
now involved in some lower volume DB stuff and the cheapest we can get the
HW is far more than a couple of thousand, and that is ignoring all the
people costs of any work.

Yeah, I know.
Basically the contractors are saying "to get from Bradford to London you
need to build a motorway". However the motorway is already mostly there. All
you need to do is buy a car, and maybe link up a little bit round the Leeds
area.
The number of accesses that medical staff need to make to medical records is
far less than total internet usage in the country. All the hardware and
software infrastructure is already there, and could be bought at commerical
rates, not quite for two thousand pounds, but certainly very cheaply.
The two thousand pounds was my fee for setting up such a system. There's
basically a months' work there for someone. Set up a web server with editing
capabilities, an audit history, and password protection.
Now granted that medical records need to be secure, but not that secure. It
would be embarrassing for Mrs Bloggs if some unathorised person knew that
she had a hernia op, but it would take a creative villain to turn that
information into cash. Meanwhile if a doctor cannot access the same
information in an emergency, because of the security, it might be bye bye
Mrs Bloggs. We're talking about ordinary commerical level type security
here, not release codes for our nuclear weapons. If you want to spend a
hundred pounds per doctor for a little dongle that fits into a USB port
rather than raw passwords then I won't complain too much. However this
consideration used as an excuse for wasting literally bilions of taxpayers'
money.

Incidentally salesmen always say that people offering radically lower bids
don't understand the problem, or aren't qualified. It is a standard
technique.

 

[Flash Gordon]

Malcolm McLean wrote, On 05/05/07 13:00:

Incidentally salesmen always say that people offering radically lower
bids don't understand the problem, or aren't qualified. It is a standard
technique.

This is all off topic here, so my last word on the matter is you
obviously don't know what you are talking about because even the
cheapest version of the hardware required for the data storage costs
more like 20,000 a pop, and you need it at a minimum of 2 sites, and you
would need to go rather higher up the line for the requirements. Also
with your attitude to the security required I would not want you having
anything to do with the storage of any of my personal data.

It's a government project, so I'm sure lots of money is being wasted,
but I know enough (as my company provides hosted services with a lower
volume and much slacker SLAs) to know that it requires a lot more
investment that you are claiming.

I note you failed to respond to the response on the less off-topic part
of the conversation, where I pointed out that there are programmers who
are not idiots available, so your claiming you can't get rid of idiot
programmers because that is all that is available was wrong.

 

[Kenny McCormack]

If you insist on writing unsafe code, nobody can stop you. It's
trivial to write your own function that works the same way gets()
does.

It is *not* trivial. It is impossible, to write a drop-in replacement
for gets() that is safe (*). That's the whole point (**).

(*) Without hardware support.

(**) Of course, a literal reading will tell us that:

char *Gets(char *s) { return gets(s); }

does "work the same way as gets()" - warts and all - but I don't think
that's what is meant.

 

[Kenny McCormack]

No conditions except that of the file and of the malloc subsystem.
Besides, it has been around for about 5 years, and I have had zero
reports of insects.

I think they are referring to "conditions" in the code - in the sense of
complex login (if statements).

Though, I note, that your reading was my first reading as well.

 

[Kenny McCormack]

I'd be happy around here to be considered competent. On the other hand,
for my "skills assessment" at work, I blithely checked "expert" level
for C.

Doesn't everybody?

 

[Richard Tobin]

It is *not* trivial. It is impossible, to write a drop-in replacement
for gets() that is safe (*). That's the whole point (**).

I think Keith meant it was trivial to write a replacement with the
same unsafe behaviour as gets().

-- Richard

 

[Malcolm McLean]

I think Keith meant it was trivial to write a replacement with the
same unsafe behaviour as gets().

What people, I won't speak for Keith, usually mean is that

void mygets(char *str, int len)
{
char *ptr;

fgets(str, len, stdin);
ptr = strchr(str, '\n');
if(ptr)
*ptr = 0;
}

is safe. It isn't. It doesn't show UB but it makes it impossible to treat
partial reads correctly, except in the unusual case where the file grammar
ignores newlines.

 

[Richard Heathfield]

Malcolm McLean said:

What people, I won't speak for Keith, usually mean is that

void mygets(char *str, int len)
{
char *ptr;

fgets(str, len, stdin);
ptr = strchr(str, '\n');
if(ptr)
*ptr = 0;
}

is safe. It isn't. It doesn't show UB but it makes it impossible to
treat partial reads correctly, except in the unusual case where the
file grammar ignores newlines.

The function you have shown here is indeed naive, and exhibits a number
of problems other than the one you pointed out. So what? There is no
shortage of naive programmers. The fact that it is easy to get this
wrong does not mean that it is difficult to get it right.

 

[Keith Thompson]

I think Keith meant it was trivial to write a replacement with the
same unsafe behaviour as gets().

Exactly. If gets() is removed from the standard, and implementations
stop supporting it, anyone who misses it can easily recreate it.

Such programmers would be far better off writing something *better*
than gets(), but as I've said before, if people insist on writing
unsafe code, the language isn't going to stop them. You can still
shoot yourself in the foot, but the language standard IMHO shouldn't
hand you a gun that automatically aims itself at your foot and pulls
its own trigger. (Yes, I'm stretching the metaphor to absurd
lengths.)

 

[Malcolm McLean]

Malcolm McLean said:


The function you have shown here is indeed naive, and exhibits a number
of problems other than the one you pointed out. So what? There is no
shortage of naive programmers. The fact that it is easy to get this
wrong does not mean that it is difficult to get it right.

That's a good point. If something is easy to get wrong does that mean it is
difficult to get right?
Thne problem with fgets() is that, even when you point out the problems,
people still don't get it. They are so fixated on avoiding the UB on buffer
overrun that they ignore all the other ways the code can go wrong.

 

[Richard Heathfield]

Malcolm McLean said:

That's a good point. If something is easy to get wrong does that mean
it is difficult to get right?
No.

Thne problem with fgets() is that, even when you point out the
problems, people still don't get it.

Some people do, and others don't. The people that do can use fgets
safely. Of the people that don't, some can be taught and some can't.
The ones who can be taught are not a problem - simply teach them. The
ones who cannot be taught how to use fgets safely are more of a
problem. As already pointed out, one typical fix is to promote them.

They are so fixated on avoiding
the UB on buffer overrun that they ignore all the other ways the code
can go wrong.

Not everyone is cut out to be a programmer.

 

[Richard Tobin]

Thne problem with fgets() is that, even when you point out the problems,
people still don't get it. They are so fixated on avoiding the UB on buffer
overrun that they ignore all the other ways the code can go wrong.

I don't think that's so unreasonable. Some kinds of "going wrong" are
more serious than others. If an ftp server sends you the wrong file -
or more likely, gives you an error message - because it divided up the
line incorrectly, that's less serious than if it executed some
arbitrary code because of a buffer overflow.

Programs don't have to be perfect.

-- Richard

 

[Kenny McCormack]

I think Keith meant it was trivial to write a replacement with the
same unsafe behaviour as gets().

What people, I won't speak for Keith, usually mean is that

void mygets(char *str, int len)[/QUOTE]

My point is that that function is not "drop-in" compatible with gets(),
because its signature is different. That means you can't use it without
re-writing all of your code base that uses gets().

Two notes:
1) You might argue that because it has a different name ("mygets"), it
wouldn't be drop-in compatible anyway (i.e., you'd have to edit your
code to use it). But the fact is that IRL, you'd use some trickery of
your OS/platform to allow the function name to be "over-loaded" and thus
not have to change the name. Of course, we can't talk about it (*) here.
2) The real problem with the above is in an existing code base, it may
not be obvious what value to use for "len" (without analyzing the code).
So, again, not a drop-in.

(*) Subliminal man says: LD_PRELOAD...

 

[Malcolm McLean]

Thne problem with fgets() is that, even when you point out the problems,
people still don't get it. They are so fixated on avoiding the UB on
buffer
overrun that they ignore all the other ways the code can go wrong.

I don't think that's so unreasonable. Some kinds of "going wrong" are
more serious than others. If an ftp server sends you the wrong file -
or more likely, gives you an error message - because it divided up the
line incorrectly, that's less serious than if it executed some
arbitrary code because of a buffer overflow.
From elsethread
* Let's consider a program that calculates drug doses for diabetics. I
* can't be a doctor without my little black bag, so we'll have five
* machines in the bag just in case.
*
*We enter a line.
*Mr Cyril M Kornbluth, sugar level 3000
*The level is calculated by another machine that was written in Visual
*Basic, and works.
*It is in micromoles per ml.
*
*This is the output
*Machine A
*Line too long, please enter only patient intials.
*Machine B
*This machine has performed illegal operation
*Machine C
*sdfgjhkeutrpitnhfc,s[n !!!!!
*Machine D
*Inject 6000ml insulin
*Machine E
*Inject 2ml insulin

 

[Richard Tobin]

I don't think that's so unreasonable. Some kinds of "going wrong" are
more serious than others. If an ftp server sends you the wrong file -
or more likely, gives you an error message - because it divided up the
line incorrectly, that's less serious than if it executed some
arbitrary code because of a buffer overflow.

[/QUOTE]

From elsethread

Why? Most programs don't do that. In some contexts using a truncated
line could be disastrous, but that's not usually the case.

I don't see anyone complaining that kitchen scales are not suitable for
weighing insulin doses.

-- Richard

 

[Flash Gordon]

Malcolm McLean wrote, On 07/05/07 19:27:

Thne problem with fgets() is that, even when you point out the problems,
people still don't get it. They are so fixated on avoiding the UB on
buffer
overrun that they ignore all the other ways the code can go wrong.

I don't think that's so unreasonable. Some kinds of "going wrong" are
more serious than others. If an ftp server sends you the wrong file -
or more likely, gives you an error message - because it divided up the
line incorrectly, that's less serious than if it executed some
arbitrary code because of a buffer overflow.
From elsethread
* Let's consider a program that calculates drug doses for diabetics. I
* can't be a doctor without my little black bag, so we'll have five
* machines in the bag just in case.
*
*We enter a line.
*Mr Cyril M Kornbluth, sugar level 3000
*The level is calculated by another machine that was written in Visual
*Basic, and works.
*It is in micromoles per ml.
*
*This is the output
*Machine A
*Line too long, please enter only patient intials.
*Machine B
*This machine has performed illegal operation
*Machine C
*sdfgjhkeutrpitnhfc,s[n !!!!!
*Machine D
*Inject 6000ml insulin
*Machine E
*Inject 2ml insulin

Or due to arbitrary code execution it injects the wrong drug in to
either that patient or the next patient.

Of course, the program that produces an output not acceptable as input
to the intended programs is faulty, despite what the above said.

Also the behaviour when defined but incorrect is more likely to cause a
test to fail than undefined behaviour, especially behaviour so obviously
wrong.

All this and more was pointed out when the above was posted before, but
you seem to have not understood it.