I
Ian Collins
They would be much clearer as functions rather than macros.
If you disagree, discuss them and see where it ends up, others may back
you up.
They would be much clearer as functions rather than macros.
If you disagree, discuss them and see where it ends up, others may back
you up.
S
shane
Ian 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.
I
Ian Collins
Better a clever macro than a clear function
The only clever macro is one that does something a function can't!
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:
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.
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:
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
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.
A promise is different from no promise...
K
Kenny McCormack
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
"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:
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
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.
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:
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
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
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.