Impossible question?

[Seebs]

For the other suggestion, I think abort is a good way of exiting, it lets
users debug what went wrong from the core dump.

It also prevents them from doing anything about it, or catching errors,
or responding to them in any way. Not good at all.

-s

 

[Keith Thompson]

Your right, I have now implemented some cool macros to improve the
interface. I also enlarged the gets buffer to address people's concerns
that 20 wasn't long enough on 64-bit ints. Other invalid input - well
garbage in garbage out...

[...]

The problem isn't that 20 characters isn't long enough for 64-bit
ints. The problem is that *no* buffer can be big enough to be used
safely with gets().

gets() is inherently unsafe. Except in very unusual circumstances
where you have complete control over what appears on stdin, it
cannot be used safely. Whatever buffer size you specify, the user
can provide more input than gets() can handle, and gets() will
scribble over memory outside your buffer. (This was exploited by
the Morris Worm of 1988.)

Never use gets(), not even in a toy program.

Read question 12.23 of the comp.lang.c FAQ, <http://c-faq.com/>.

 

[Keith Thompson]

Your right, I have now implemented some cool macros to improve the
interface. I also enlarged the gets buffer to address people's concerns
that 20 wasn't long enough on 64-bit ints. Other invalid input - well
garbage in garbage out...

[...]

The problem isn't that 20 characters isn't long enough for 64-bit
ints. The problem is that *no* buffer can be big enough to be used
safely with gets(). [snip]

Never use gets(), not even in a toy program.

Read question 12.23 of the comp.lang.c FAQ, <http://c-faq.com/>.

I should have taken the time to read the rest of the article before
posting a followup. shane has, as far as I can tell, systematically
ignored every piece of good advice he's gotten here. I conclude
that he's a troll, or is practically indistinguishable from one.

shane, feel free to prove me wrong by starting to pay attention to
what we've been telling you.

 

[Kenny McCormack]

I should have taken the time to read the rest of the article before
posting a followup. shane has, as far as I can tell, systematically
ignored every piece of good advice he's gotten here. I conclude
that he's a troll, or is practically indistinguishable from one.

So there you have it, gentlemen. What more evidence do you need?

Kiki's definition of a troll is someone who doesn't like (by showing the
proper tribute) what he (Kiki) tells him.

That's all you have to do in this newsgroup, folks, to get branded a
troll, is disagree with Kiki. Or not fall over yourself in tribute at
whatever nonsense he throws your way.

 

[Nick Keighley]

[...] I also enlarged the gets buffer to address people's concerns
that 20 wasn't long enough on 64-bit ints. Other invalid input - well
garbage in garbage out...

The problem isn't that 20 characters isn't long enough for 64-bit
ints.  The problem is that *no* buffer can be big enough to be used
safely with gets().

gets() is inherently unsafe.  Except in very unusual circumstances

Complete nonsense of course as you go on to admit

where you have complete control over what appears on stdin,

I call that fairly unusual. The cost of using fgets is pretty small so
why use the inherently unsafe one when you don't have to?

Which is loads of programs which pipe known data sizes to each other in
a closed system.


There is nothing wrong with it.

What next? Dont use pointers in case one is null becuase of a bug?

you're comparing apples with geckos. Pointers can be used safely.
gets() can't be made safe, except when you have perfect control over
stdin. And are you sure you're going to have that degree of control
over stdin in the future?

<snip>

 

[Kenny McCormack]

you're comparing apples with geckos. Pointers can be used safely.
gets() can't be made safe, except when you have perfect control over
stdin.

You know, I honestly believe that Nick and the CLC regs don't understand
simple English construction. They don't understand what the word "except"
means. I'm 100% serious about this.

Sample CLC logic:

Premise: It is dark all the time except during the day ("day" being
defined as that period of time when it is light - i.e., not dark - out)

Conclusion: It is dark all the time.

 

[Tim Streater]

You know, I honestly believe that Nick and the CLC regs ...

Such as yourself and "Richard", for example.

 

[Kenny McCormack]

Such as yourself and "Richard", for example.

We're not regs. That's the dumbest argument anyone can make - the idea
that you can consume your opponents by asserting that they are just like
you.

It's like when religionists/creationists assertt that atheism (and/or
knowledge of evolution) is a religion just like their own. Stupid
beyond belief, but it seems to attract a loyal following.

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

 

[Tim Streater]

We're not regs.

Oh, how precious. Look, don't give me that shit. A reg - someone who
posts regularly. Or is the concept too hard for you? I know you like to
define those you dislike here as regs, but it won't wash.

 

[Kenny McCormack]

Oh, how precious. Look, don't give me that shit. A reg - someone who
posts regularly. Or is the concept too hard for you? I know you like to
define those you dislike here as regs, but it won't wash.

I coined the term, so, yes, I get to define it.

Sensible people here, including you, know perfectly well the
distinction, even if they feign ignorance (as you are doing).

 

[Squeamizh]

Such as yourself and "Richard", for example.

Arguing with Kenny and Richard is never productive. Wouldn't it be
nice if no one ever replied to them?

 

[Nick]

Arguing with Kenny and Richard is never productive. Wouldn't it be
nice if no one ever replied to them?

Very very few people now do. I have them both killfiled and see about 1
or 2 quoted posts a week. They still seem to post half a dozen messages
a day, but I think they are talking to themselves these days.

 

[Tim Streater]

I coined the term, so, yes, I get to define it.

Sensible people here, including you, know perfectly well the
distinction, even if they feign ignorance (as you are doing).

<yawn>

Wake me up when you have something sensible to say.

 

[Nick Keighley]

So can gets.


Did you even read what I said before replying with stock c.l.c closed
minded nonsense Nick?

yes I read what you wrote. And I disagreed with it. You got my
considered opinion.

That what I said : when you have control. Which you, as a programmer
do. If someone else wants to use my code they can replace the gets
calls.

It CAN be used safely. End of story.

Tell me, whats your opinion of something like

strcpy( s1,s2);

Can strcpy be used "safely" in case the source is suddenly longer than
the original programmer intended?

I'd expect there would be some way of verifying that s2 would fit in
s1. I'm not a fan of microsoft's "safe" string extensions.

I distinguish the internals of a program, which I have control over
and the externals which I don't.

I won't bother tocontinue this if we just loop over the same opinions
repeatedly

Think. Open your eyes. Dont repeat group mantras.

don't knee-jerk contradict things for the sake of it. Not everything a
"clc regular" says is wrong.

 

[Nick Keighley]

Tell me, do you null check pointers each and every time you use them?

I'd expect some sort of gurantee that a pointer wasn't null before I
dereferenced it. I use assert (ptr != NULL) quite a lot too

 

[Nick Keighley]

You know, I honestly believe that Nick and the CLC regs don't understand
simple English construction.  They don't understand what the word "except"
means.  I'm 100% serious about this.

no you aren't. I understand what "except" means. That's why I used it.
I regard the "perfect control over input" case to be so unusual and
brittle as to be almsot useless.

But I think the cost/benefit of fgets over gets is simply too good to
ignore.

Sample CLC logic:

Premise: It is dark all the time except during the day ("day" being
defined as that period of time when it is light - i.e., not dark - out)

Conclusion: It is dark all the time.

its safe to walk about in the open, except when meterorites land,
conclusion it is not safe to walk about in the open.

You sure it's me that doesn't understand what "except" means?

 

[Nick Keighley]

Very very few people now do.  I have them both killfiled and see about 1
or 2 quoted posts a week.  They still seem to post half a dozen messages
a day, but I think they are talking to themselves these days.

I reply to them if they make technical sense or they say something
that might confuse a lurker

 

[Kenny McCormack]

don't knee-jerk contradict things for the sake of it. Not everything a
"clc regular" says is wrong.

Granted. They usually get their name right.

--
One of the best lines I've heard lately:

Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)

 

[Seebs]

no you aren't. I understand what "except" means. That's why I used it.
I regard the "perfect control over input" case to be so unusual and
brittle as to be almsot useless.

It's a question of engineering principles, really. You seem to have developed
the theory that it's unwise to rely on things which are likely to change,
and experience which shows that the other end of a software interaction may
well change during the lifetime of a program.

Both positions are, of course, correct.

The theory that you can have complete control over stdin, and should rely
on it, is a theory incompatible with a reasonable amount of programming
experience.

I think there's another aspect to this being overlooked. Experienced
engineers usually get a sense for *tradeoffs*. How much work is this change,
and how much protection does it offer? Alternatively, how much work can I
save by ignoring this possible failure mode, and how much risk does that
introduce?

There is not enough benefit from using gets() to justify the risk in any
real-world circumstance, meaning that even if you found one of the theoretical
cases where it could be used "safely", it wouldn't be a particularly
beneficial choice. The time it takes to verify that it's "safe" far exceeds
the time saved by using it instead of something like fgets().

In short, while it may theoretically be the case that there exist safe calls
to gets(), there are few enough of them, and the benefit is marginal enough,
that it is perfectly reasonable to ignore the possibility. On the other hand,
unsafe calls to gets() which someone originally thought would be safe are
fairly common, and fairly risky. Conclusion: A policy of looking for safe
places to use gets(), rather than banning it entirely, creates a very large
risk of real-world buffer overflows due to programmer error or changes in
circumstances, while avoiding gets() avoids those risks.

Once you include the risks of "future changes we didn't anticipate" and
"programmer analysis incorrect", there is in fact NO way to use gets()
"safely".

-s

 

[shane]

Your right, I have now implemented some cool macros to improve the
interface. I also enlarged the gets buffer to address people's
concerns that 20 wasn't long enough on 64-bit ints. Other invalid
input - well garbage in garbage out...

[...]

The problem isn't that 20 characters isn't long enough for 64-bit ints.
The problem is that *no* buffer can be big enough to be used safely
with gets(). [snip]

Never use gets(), not even in a toy program.

Read question 12.23 of the comp.lang.c FAQ, <http://c-faq.com/>.

I should have taken the time to read the rest of the article before
posting a followup. shane has, as far as I can tell, systematically
ignored every piece of good advice he's gotten here. I conclude that
he's a troll, or is practically indistinguishable from one.

shane, feel free to prove me wrong by starting to pay attention to what
we've been telling you.

Sorry kieth but you are completely off base here. The /whole point/ of my
post was to demonstrate my response to the advice not to expliclty poke a
NULL or 0X01 byte at the end of the prompt string!! - the main difference
with the original code was a couple nifty macros to improve that
interface. I was pretty pleased with them.

As for the other suggestions, I'll think about them all, some I think are
wrong, some I disagree with... either way, I'm not going to change
perfectly good working code! Maybe in the future I'll take up some of
them.