Impossible question?

I

Ian Collins

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.

They would be much clearer as functions rather than macros.
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.

If you disagree, discuss them and see where it ends up, others may back
you up.
 
S

shane

Ian said:
They would be much clearer as functions rather than macros.

Better a clever macro than a clear function ;)
If you disagree, discuss them and see where it ends up, others may back
you up.

Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.
 
I

Ian Collins

Better a clever macro than a clear function ;)

The only clever macro is one that does something a function can't!
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

That's true, but remember

- gets adds nothing (fgets does the same job with the added bonus of
being safe...).

- the Garbage Out could be a root kit!
 
K

Keith Thompson

shane said:
Keith said:
Keith Thompson said:
[...]
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.

Ok, perhaps I missed something useful in your recent followup.

Nevertheless, you're continuing to use gets() in spite of the fact
that, as numerous people have told you, it *cannot* be used safely
(except in certain rare circumstances that do not apply to your
program).

If I run your program and give it more than N characters of input
on a single line, its behavior will be undefined. You do not have
"perfectly good working code"; you have code that can blow up in
arbitrarly bad ways that you may not have run across yet.

You've also continued to post code whose lack of whitespace makes it
quite difficult to read. Consider running it through something like
"indent -kr" if you have it on your system.
 
K

Keith Thompson

shane said:
Better a clever macro than a clear function ;) [...]
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

If a large number of people with far more experience than you almost
universally disagree with you, please consider the possibility that
they might be right and you might be wrong.
 
S

Seebs

Better a clever macro than a clear function ;)

That seems extremely unlikely.
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

And I am sure that every botnet operator in the world is glad to hear you
say it.

The problem is that "misbehaves" can include outcomes like "and then does
something really nasty because someone found a hole in your program".

Write conservatively.

-s
 
K

Kenny McCormack

shane said:
Better a clever macro than a clear function ;) [...]
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

If a large number of people with far more experience than you almost
universally disagree with you, please consider the possibility that
they might be right and you might be wrong.

http://en.wikipedia.org/wiki/Appeal_to_the_majority

Also known as: Argumentum ad populum
 
K

Kenny McCormack

Keith Thompson said:
You've also continued to post code whose lack of whitespace makes it
quite difficult to read. Consider running it through something like
"indent -kr" if you have it on your system.

Maybe you should just give it up, there, Kiki. I think you and shane
are not just not going be dating.

That's the thing - so much of Kiki's posting looks like that of a jilted
lover. "I did so much for you, but you shun my advice. Boo Hoo!"

--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus
 
T

Tim Streater

Maybe you should just give it up, there, Kiki. I think you and shane
are not just not going be dating.

That's the thing - so much of Kiki's posting looks like that of a jilted
lover. "I did so much for you, but you shun my advice. Boo Hoo!"

This is how you're not a reg, then eh, Kenny? The "regs" post advice and
you just post b/s, is that it?
 
I

Ian Collins

Keith Thompson said:
shane said:
Better a clever macro than a clear function ;) [...]
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

If a large number of people with far more experience than you almost
universally disagree with you, please consider the possibility that
they might be right and you might be wrong.

He's not wrong. Not in a controlled environment.

gets is perfectly safe in those.

I'm sure you'll agree that such environments are pretty rare. Even
there, why not program defensively and use fgets()? Sods law clearly
states that code written for a closed environment will one day be used
elsewhere.
As I said : what next? Not allowed to assume destination malloc area is
big enough? Dont believe the promise that pointers are not null?

A promise is different from no promise...
 
K

Kenny McCormack

Maybe you should just give it up, there, Kiki. I think you and shane
are not just not going to be dating.

That's the thing - so much of Kiki's posting looks like that of a jilted
lover. "I did so much for you, but you shun my advice. Boo Hoo!"

This is how you're not a reg, then eh, Kenny? The "regs" post advice and
you just post b/s, is that it?[/QUOTE]

I think you are beginning to get it. Well done.

But we prefer to call it "Social Commentary". Please use this term in
future. Thank you.

--
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.)
 
K

Keith Thompson

Ian Collins said:
Keith Thompson said:
[...]
Better a clever macro than a clear function ;)
[...]
Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

If a large number of people with far more experience than you almost
universally disagree with you, please consider the possibility that
they might be right and you might be wrong.

He's not wrong. Not in a controlled environment.

gets is perfectly safe in those.

I'm sure you'll agree that such environments are pretty rare. Even
there, why not program defensively and use fgets()? Sods law clearly
states that code written for a closed environment will one day be used
elsewhere.

And it doesn't seem particularly likely that shane is working in
such a "controlled environment". He hasn't claimed that he can
prevent long input lines; instead, he's said that he doesn't care
what happens if the user provides a long input line.
 
L

luser- -droog

Theres already been a lot of discussion on gets. My 2c is that if someone
inputs a stupid integer value and the program misbehaves well what do
they expect? Garbage In, Garbage Out.

"Garbage In, Garbage Out" seems more like a lamentable state of
affairs,
and not a worthwhile goal. Given the choice, wouldn't you prefer a
program
not to wreak havoc?
 
S

shane

Seebs said:
That seems extremely unlikely.

Hehe, guess you've lost your sense of fun over the years. I get a warm
glow of pride just looking at these macros :)

#define str_to_prompt_nocheck(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);s=t;}while(0);
#define str_to_prompt_check(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);(*(++t+strlen(s)))++;s=t;}while(0);

When I see macros like this I think "jeez, the guy who wrote them must be
pretty darn clever..."
 
I

Ian Collins

Hehe, guess you've lost your sense of fun over the years. I get a warm
glow of pride just looking at these macros :)

#define str_to_prompt_nocheck(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);s=t;}while(0);
#define str_to_prompt_check(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);(*(++t+strlen(s)))++;s=t;}while(0);

When I see macros like this I think "jeez, the guy who wrote them must be
pretty darn clever..."

More like "smart arse"!

What's wrong with

void str_to_prompt_nocheck( char** s )
{
const size_t newSize = strlen(*s)+2; /* Don't call strlen twice! */

char* t = malloc(newSize);
strncpy(t,*s,newSize);
*s=t;
}
 
S

Seebs

Hehe, guess you've lost your sense of fun over the years.

No. I just have a sense of fun which does not revolve entirely around
spending a ton of time trying to figure out something that the debugger
can't correctly display which is failing for a non-obvious reason.
I get a warm
glow of pride just looking at these macros :)

Wow. That's... Not good.
#define str_to_prompt_nocheck(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);s=t;}while(0);
#define str_to_prompt_check(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);(*(++t+strlen(s)))++;s=t;}while(0);
When I see macros like this I think "jeez, the guy who wrote them must be
pretty darn clever..."

When I see them, I think "jeez, the guy who wrote these must think he's
pretty darn clever."

Look at it this way: If I got a bug report involving some code, and I
saw those macros in it, I would reject the bug report and say "submit this
with a stripped-down reproducer." Because I would have justified confidence
in believing that the bug was in the submitted code, not in the compiler.
I don't have to find the bug to recognize code which has characteristics
which show that it will be buggy.

Code like that is a big red warning flag that it was written by someone who
has learned enough to be dangerous, but hasn't yet learned any kind of
judgement. The code will be littered with things that look "clever" and which
probably often work except under very mildly uncommon circumstances, but which
fail catastrophically or surprisingly in those uncommon circumstances.

If someone asked me to maintain something like that, I'd send back an
estimate on what it would take to write a new one from scratch, confident
that within a few months of use, it would have been a substantially lower
investment of programmer time.

You know what's fun? Fun's not having to put in 70-hour weeks to try to
get stuff running again when it was all held together by duct tape and baling
wire.

-s
 
T

Tim Streater

Seebs said:
No. I just have a sense of fun which does not revolve entirely around
spending a ton of time trying to figure out something that the debugger
can't correctly display which is failing for a non-obvious reason.


Wow. That's... Not good.



When I see them, I think "jeez, the guy who wrote these must think he's
pretty darn clever."

Look at it this way: If I got a bug report involving some code, and I
saw those macros in it, I would reject the bug report and say "submit this
with a stripped-down reproducer." Because I would have justified confidence
in believing that the bug was in the submitted code, not in the compiler.
I don't have to find the bug to recognize code which has characteristics
which show that it will be buggy.

Code like that is a big red warning flag that it was written by someone who
has learned enough to be dangerous, but hasn't yet learned any kind of
judgement. The code will be littered with things that look "clever" and which
probably often work except under very mildly uncommon circumstances, but which
fail catastrophically or surprisingly in those uncommon circumstances.

If someone asked me to maintain something like that, I'd send back an
estimate on what it would take to write a new one from scratch, confident
that within a few months of use, it would have been a substantially lower
investment of programmer time.

You know what's fun? Fun's not having to put in 70-hour weeks to try to
get stuff running again when it was all held together by duct tape and baling
wire.

Damn good summary. The guy who wrote the macros may be "pretty darn
clever", but I'd want to know who he was so I could avoid his code like
the plague. A word to the wise, huh, Shane? Don't say stuff like that in
job interviews. You'll find the interview to be surprisingly short.
 
B

Ben Bacarisse

shane said:
Hehe, guess you've lost your sense of fun over the years. I get a warm
glow of pride just looking at these macros :)

#define str_to_prompt_nocheck(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);s=t;}while(0);
#define str_to_prompt_check(s) do{char* t=malloc(strlen(s)+2);strncpy
(t,s,strlen(s)+2);(*(++t+strlen(s)))++;s=t;}while(0);

When I see macros like this I think "jeez, the guy who wrote them must be
pretty darn clever..."

I don't think you do. I think you are just winding people up (and
there's no real harm in that; if I don't want to be wound up I'll walk
away).

Why would you think it's clever to take three obvious statements and
wrap them in an incorrect use of the do {...} while (0) idiom? You
can't be feeling pleased because you've just re-invented the idiom,
because, in that case, you'd have got it right. It not credible to see
why you need it but then to get the key part of it wrong. So you just
copied it from somewhere that had also got it wrong, or you copied it
wrongly from somewhere that had got it right.

So where does the warm glow come from? Is it from needlessly calling
strlen three times? Maybe from not testing the return from malloc? Or
maybe just from writing a single 122 character long line with only three
spaces? (By the way, did you know that two of them are not needed!?)

No, I think it comes from sneaking a bug past everyone inside your
"clever" macros. Am I right?
 
M

Malcolm McLean

The time it takes to verify that it's "safe" far exceeds
the time saved by using it instead of something like fgets().
Well it took over 200 posts to this newsgroup to explan the problems
with fgets(). Eventually the penny dropped, but even experienced
programmers like our FAQ maintainer were getting hot under the collar
and threatening to killfile. My conclusion is that most human
programmers aren't skilled enpugh to use fgets() safely and it takes
an unreasonably long time to train them to do so.

Meanwhile gets() can be implemented safely, of course. Often it is
implemented with reasonable safety (safe except in the case of
malicious attack, which if the program is operating in an environment
where a C compiler is avialable, isn't a serious concern).
 
M

Malcolm McLean

Really?  How can gets() be implemented safely?  How can a program
that calls gets() deal with long input lines from stdin?

The C standard's specification of gets() doesn't permit it to be
implemented safely.
Consider an implementation with fat pointers, in C terms

struct fat
{
void *ptr;
void *start;
void *end;
}

every attempt to modify the ptr member is checked to make sure it
doesn't go past end.

Now gets() can be implemented so that it always issues a diagnostic
error message and terminates the program on buffer overflow. Given
that the programmer doesn't know how to handle long inputs, this is
both safe and the safest thing it can do.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top