gets() - dangerous?

[Jordan Abel]

#ifdef CORRECT
#include <stdlib.h>
#endif

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.

 

[Joe Wright]

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.

Nonsense. The compiler does not imply how to fix anything. It has issued
a diagnostic about having encountered an unusual condition. It is up to
the programmer to determine whether the condition is an error and what
to do about it.

 

[Kenny McCormack]

Nonsense. The compiler does not imply how to fix anything. It has issued

Hint when reading CLC:

Any post that starts out with a blanket "Nonsense" is proof
positive that the poster is FOS.

HTH.

 

[Jordan Abel]

Nonsense. The compiler does not imply how to fix anything. It has issued
a diagnostic about having encountered an unusual condition.

The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an example of
poor quality-of-implementation, slightly worse, in my opinion, than,
say, "E#42".

A good warning message for this condition would be, say, "Implicitly
declared function returns integer where user seems to expect a pointer
for assignment to (lvalue expression)" or a separate diagnostic about
the implicit declaration.

Even lint's "illegal combination of pointer and integer, op = [123]" is
a step above the gcc message, since it doesn't appear (to an uninformed
reader) to suggest a cast as the solution.

 

[Jordan Abel]

Steve Summit said:


I tried that, too. It's entirely up to you, of course, but it's hard enough
to generate high quality content in a /neutral/ environment, let alone when
anyone can negate your changes on a whim because they think you're wrong
about, say, main returning int or whatever.

Just fixing the errors is an approach that seems to work - it's easier
to defend a single change than a rewrite.

 

[Richard Heathfield]

Jordan Abel said:

Other than wrapping you introduced, this example looks syntactically
correct, which is what the article's about - and anyway why don't you
fix it - I'm sure that an expert like you working on the article would
be very helpful

I don't see the point. I've tried editing the Wiki before, and my changes
were all but emasculated within a day or so.

Other than the comments, i don't see any c90 bugs. i don't see any c99
bugs at all.

I will suppress my urge to respond sarcastically, because I know you're a
white-hat underneath. But if you can't see the bugs, I suggest you look a
bit closer.

 

[Jordan Abel]

Jordan Abel said:


I don't see the point. I've tried editing the Wiki before, and my changes
were all but emasculated within a day or so.



I will suppress my urge to respond sarcastically, because I know you're a
white-hat underneath. But if you can't see the bugs, I suggest you look a
bit closer.

stdlib.h isn't included, but neither is anything else, and it's arguably
just a code snippet, not a real program. Didn't I say that?

Were there any other bugs you had in mind?

 

[Malcolm]

The advice not to cast the result of malloc() isn't just a "bit of
trivia". It avoids real errors in real programs, and it's something
that any C programmer needs to understand.

<snip non-inclusion of stdlib.h morality story>

I've been won over to the party of the non-casters, though not mainly for
that reason.

Bascially, a non-cast malloc() is less visual clutter than a cast one.
Is this trivia? Yes, if we are only talking about one line. However when you
have a program with many lines, doing something intricate, then every bit of
unnecessary verbiage adds up cumulatively, making the code more and more
difficult to read. The more difficult to read, the harder to find bugs.

The reason for casting was to cut and paste into C++. However I've virtually
given up on using C++ anyway. This wasn't a conscious decision, I've just
used it less and less and now it's virtually faded from my code base.

 

[Chuck F.]

.... snip ...

Nonsense. The compiler does not imply how to fix anything. It
has issued a diagnostic about having encountered an unusual
condition.

The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an
example of poor quality-of-implementation, slightly worse, in my
opinion, than, say, "E#42".

A good warning message for this condition would be, say,
"Implicitly declared function returns integer where user seems
to expect a pointer for assignment to (lvalue expression)" or a
separate diagnostic about the implicit declaration.

Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.

It is up to the programmer to determine whether the condition
is an error and what to do about it.

Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message. It is the assignment of incompatible
types that provokes the warning. The fact that one type came from
a function has long since escaped the view of the compiler. The
cure (in the original) is to provide a proper function prototype,
thus avoiding the assumption of an incorrect type in the first place.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

Jordan Abel said:

stdlib.h isn't included

That's the principal problem, and in C99 that means a diagnostic is required
for the malloc call.

but neither is anything else, and it's arguably
just a code snippet, not a real program.

That wasn't the impression I got from the code.

Were there any other bugs you had in mind?

I can't remember now and I don't care enough. Sorry. IIRC, the major problem
was the lack of inclusions, which caused several problems with the code.

 

[Keith Thompson]

Note that this is the source of the bug, not the cast. The cast neither
creates a bug nor does omitting it cause there not to be one. However,
the real bug is in the compiler - for saying "makes pointer from integer
without cast" thus implying that a cast is the correct way to fix the
bug.

Ok, but the fact is that conforming compilers can, and often do,
produce inadequate or even misleading diagnostic messages. A cast
tells the compiler, "shut up, I know what I'm doing", which is
especially dangerous when you *don't* know what you're doing.
Avoiding unnecessary casts (most casts are unnecessary) is a way to
defend yourself against poor diagnostics.

Adding a cast is a common technique for eliminating a compiler
warning, but it's like taping over a red warning light on your car's
dashboard.

 

[Jordan Abel]

... snip ...

Nonsense. The compiler does not imply how to fix anything. It
has issued a diagnostic about having encountered an unusual
condition.

The text of the diagnostic is a quality-of-implementation issue.
"Assignment makes pointer from integer without cast" is an
example of poor quality-of-implementation, slightly worse, in my
opinion, than, say, "E#42".

A good warning message for this condition would be, say,
"Implicitly declared function returns integer where user seems
to expect a pointer for assignment to (lvalue expression)" or a
separate diagnostic about the implicit declaration.

Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.

It is up to the programmer to determine whether the condition
is an error and what to do about it.

Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message.

Says who? That's a quality-of-implementation issue.

 

[Mark McIntyre]

I recently read about a new wiki-style encyclopedia which is in the
works. They are using a two-tiered system, as I understand it.

(Sorry I don't have a reference to the new encyclopedia.)

This one?

http://www.theregister.co.uk/2005/12/19/sanger_onlinepedia_with_experts/
Mark McIntyre

 

[Netocrat]

On Fri, 30 Dec 2005 09:26:28 -0700, Al Balmer wrote:
[responding to discussion of how open should a c.l.c wiki be]

I recently read about a new wiki-style encyclopedia which is in the
works. They are using a two-tiered system, as I understand it. There
are invited articles written by experts in a particular field. The
article are identified as being authoritative, and editing is
restricted. However, anyone is free to add and edit other entries on
the same subject. Perhaps something like this would be appropriate.

That seems like a good idea. How about this: rather than an editorial
group to whom edits are restricted, that group is instead an expert review
group - with election/demotion as currently suggested in the charter.
Editing is open to anyone, but members of the review group are capable of
marking a particular article version as "stable" or "reviewed", and that
version is the one displayed by default (and marked as such).

The Wikipedia developers are working on code similar to this, so given
that the voting extension is mostly complete, this idea shouldn't take
much effort to incorporate into the prototype wiki.

(Sorry I don't have a reference to the new encyclopedia.)

As Mark McIntyre's pointed out, it seems likely to be Digital Universe,
backed in part by a Wikipedia founder and apparently opening early
2006. Larry Sanger's comments in the Slashdot article are pretty
informative:
<http://slashdot.org/article.pl?sid=05/12/21/2351211&tid=95&tid=99>

 

[websnarf]

The general tone of Wiki is "articles written by 'informed laymen'" - that
is, at sort of the "college football level" (obscure reference - I'll
explain if needed). It is not reasonable to expect them to be done to the
level of religious-fervor/dot-all-the-Is-cross-all-the-Ts level that is
common/expected in this newsgroup.

You misunderstand. Any technical article is exactly as accurate/deep
as the person with the most skill or knowledge who comes across the
article *and* cares about the content of the article can possibly make
it. If it doesn't measure up to your standards, either that's a
temporary situation, or you don't care that it doesn't measure up (or
it has been sabotaged -- but that's temporary too). Its that simple --
there really aren't any other possibilities.

I don't pull punches in my edits just because it might be beyond what
the reader is looking for. You just have to avoid "original research"
level content (because they don't have a way of weeding out "crackpot
theories"). Just stuff that's widely accepted, or technically correct.

Remember, as long as you care, there is never a good reason why any
content on Wikipedia should be below your own knowledge. It has
nothing to do with "laymen expertise" or anything like that. Its as
deadly accurate as is possible and is necessary -- and it should be
nothing less.

 

[websnarf]

Jordan Abel said:



That's the principal problem, and in C99 that means a diagnostic is required
for the malloc call.


That wasn't the impression I got from the code.


I can't remember now and I don't care enough.

And that, gentlemen, is the problem.

But if you cared: there is a discussion page in which you can explain
your changes. Obviously they were reverted by someone who didn't get
your point. Post it in the discussion, then if there is no feedback or
objections, do the core change citing your discussion as the reason for
the change, and if it gets reverted again, let the "edit war" begin --
just follow up in the discussion, I think the thing will automatically
detect the escalation, and it will eventually be judged on its merits.
To see an example of this look at the Buffer Overflow article in which
I am involved in a heavy discussion of the current state of it -- the
article has almost certainly been getting better as a result.

 

[Richard Bos]

Jordan Abel wrote:

Even lint's "illegal combination of pointer and integer, op =
[123]" is a step above the gcc message, since it doesn't appear
(to an uninformed reader) to suggest a cast as the solution.

It is up to the programmer to determine whether the condition
is an error and what to do about it.

Now try:

pointytypedthing = (2 + 3 + 4005);

which should raise the same conditions at assignment time, and thus
the same warning message. It is the assignment of incompatible
types that provokes the warning. The fact that one type came from
a function has long since escaped the view of the compiler.

It is, however, enimently arguable that such forgetfulness is an
imperfection in a compiler.

Richard

 

[Deiter]

And that, gentlemen, is the problem.

But if you cared: there is a discussion page in which you can explain
your changes. Obviously they were reverted by someone who didn't get
your point. Post it in the discussion, then if there is no feedback or
objections, do the core change citing your discussion as the reason for
the change, and if it gets reverted again, let the "edit war" begin --
just follow up in the discussion, I think the thing will automatically
detect the escalation, and it will eventually be judged on its merits.
To see an example of this look at the Buffer Overflow article in which
I am involved in a heavy discussion of the current state of it -- the
article has almost certainly been getting better as a result.

<ot>
I have to agree with this. If an "Open Source Document" which is
available for one's knowledge improvement is incorrect, then I feel we
should take it upon ourselves to correct the document. This being for
the betterment of open information.

This thought could be extended to the biggest problem (in my opinion)
with open source software: The lack of thorough and well structured
documentation. We should all effort to pitch in where improvement is
needed, regardless of the domain.

Deiter
</ot>

 

[Christian Bau]

<ot>
I have to agree with this. If an "Open Source Document" which is
available for one's knowledge improvement is incorrect, then I feel we
should take it upon ourselves to correct the document. This being for
the betterment of open information.

This thought could be extended to the biggest problem (in my opinion)
with open source software: The lack of thorough and well structured
documentation. We should all effort to pitch in where improvement is
needed, regardless of the domain.
</ot>

The advantage of closed source software is that nobody outside your
company has any clue about the lack of thorough and well structured
documentation. Or the lack of documentation in the first place. Come to
think of it, people can't see the appalling quality of code either. (One
reason why a lot of software will never be open sourced is the amount of
work that would have to be invested to change it to a state where a
company could publish it without being ashamed or being afraid of being
sued).

 

[Richard Heathfield]

(e-mail address removed) said:

And that, gentlemen, is the problem.

Yes, absolutely. I don't see the point in caring about an ignorance
repository.