gets() - dangerous?
Lee
Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow? Is it correct that the program flow can
be altered by giving some specific calculated inputs to gets()? How
could anyone do so once the executable binary have been generated? I
have heard many of the security problems and other bugs are due to
array overflows.
Looking forward to your replies.
Lee
Jack Klein
comp.lang.c:
The solution is simple: don't use gets(). Not ever. As to what
happens if you do use gets() and the quantity of input is greater than
the destination space, the C language does not know or care. As to
how this undefined behavior might be exploited by someone with
malicious intent, that too is not a language issue.
The authors of your compiler, quite properly and responsibly, take it
upon themselves to warn you that you should not use gets(). Why are
you still using it?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Barry Schwarz
>Hi
>
> Whenever I use the gets() function, the gnu c compiler gives a
>warning that it is dangerous to use gets(). Is this due to the
>possibility of array overflow? Is it correct that the program flow can
Yes
>be altered by giving some specific calculated inputs to gets()? How
Yes
>could anyone do so once the executable binary have been generated? I
>have heard many of the security problems and other bugs are due to
>array overflows.
>
>Looking forward to your replies.
Don't hold your breath. Buffer overflow is not a c language topic.
<<Remove the del for email>>
nickptar
Barry Schwarz wrote:
> Don't hold your breath. Buffer overflow is not a c language topic.
But is well documented elsewhere:
http://en.wikipedia.org/wiki/Buffer_overflow
Jack Klein
in comp.lang.c:
Nothing in Wikipedia can be considered well documented without
additional credible references.
Robert Gamble
This is possibly the most poorly-written and inaccurate article I have
read on wikipedia, did you even read it before posting the link?
Robert Gamble
Chuck F.
>> a warning that it is dangerous to use gets(). Is this due to
>> the possibility of array overflow? Is it correct that the
>> program flow can be altered by giving some specific calculated
>> inputs to gets()? How could anyone do so once the executable
>> binary have been generated? I have heard many of the security
>> problems and other bugs are due to array overflows.
>
> what happens if you do use gets() and the quantity of input is
> greater than the destination space, the C language does not know
> or care. As to how this undefined behavior might be exploited
> by someone with malicious intent, that too is not a language
> issue.
>
> The authors of your compiler, quite properly and responsibly,
> take it upon themselves to warn you that you should not use
> gets(). Why are you still using it?
However you can always use ggets() (note the extra g, for good).
This was written to have the convenience and simplicity of gets,
without any possible overrun. The ISO standard source (thus
portable to any system) is available at:
<http://cbfalconer.home.att.net/download/ggets.zip>
--
"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/>
Malcolm
>
> Nothing in Wikipedia can be considered well documented without
> additional credible references.
>
That's what crusty academics say because a new competitor has come along. Of
course they want people to rely on peer-reviewed literature where they are
the peers.
In fact something like 50% of scientific papers make conclusions which are
later refuted or challenged by further papers. (read Iohannis for a
peer-reviewed take on the subject).
No medium written by humans can guarantee complete accuracy, freedom form
bias, etc. Wikipedia is no different from any other source.
Richard Heathfield
> Hi
>
> Whenever I use the gets() function, the gnu c compiler gives a
> warning that it is dangerous to use gets().
No, it's the linker that warns you, not the compiler.
> Is this due to the possibility of array overflow?
Yes.
> Is it correct that the program flow can be altered by giving some
> specific calculated inputs to gets()?
Yes.
> How could anyone do so once the executable binary have been generated?
By overwriting the stack, for example. On a typical machine, the program is
loaded from disk into memory before execution. During execution, it is
present in memory. And the thing about memory is that it can be overwritten
with new values.
> I have heard many of the security problems and other bugs are due to
> array overflows.
Quite.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Giannis Papadopoulos
> "Jack Klein" <jack...@spamcop.net> wrote
>
>>Nothing in Wikipedia can be considered well documented without
>>additional credible references.
>>
>
> <OT>
> That's what crusty academics say because a new competitor has come along. Of
> course they want people to rely on peer-reviewed literature where they are
> the peers.
However, it is always useful to see where the author got the
idea/solution or based her/his own conclusions.
> In fact something like 50% of scientific papers make conclusions which are
> later refuted or challenged by further papers. (read Iohannis for a
> peer-reviewed take on the subject).
> No medium written by humans can guarantee complete accuracy, freedom form
> bias, etc. Wikipedia is no different from any other source.
Yes, for that reason papers are wrote and commented and referenced. To
prove their accuracy, correct them or throw them away.
Malcolm
>
>> No medium written by humans can guarantee complete accuracy, freedom form
>> bias, etc. Wikipedia is no different from any other source.
>
> Yes, for that reason papers are wrote and commented and referenced. To
> prove their accuracy, correct them or throw them away.
>
published. Most publications receive more material then they can or want to
print.
Further claims are then made for peer-reviewed literature, which are largely
unwarranted. In particular, peer review does not "prove accuracy".
webs...@gmail.com
> > warning that it is dangerous to use gets().
Personally, I am waiting for the compiler that implements gets as the
following:
char * gets (char * s) {
unlink (__FILE__); /* POSIX */
return s;
}
Since it would improve its predictability.
> [...] Is this due to the
> > possibility of array overflow? Is it correct that the program flow can
> > be altered by giving some specific calculated inputs to gets()? How
> > could anyone do so once the executable binary have been generated? I
> > have heard many of the security problems and other bugs are due to
> > array overflows.
> >
> > Looking forward to your replies.
> > Lee
(My recommendation is to *learn* about the problem here:
http://www.pobox.com/~qed/userInput.html )
> The solution is simple: don't use gets(). Not ever.
Hmmm ... here's a rhetorical question. What is the value of a
specifying a function in the language definition if you can't even use
it -- not ever?
> [...] As to what
> happens if you do use gets() and the quantity of input is greater than
> the destination space, the C language does not know or care. As to
> how this undefined behavior might be exploited by someone with
> malicious intent, that too is not a language issue.
>
> The authors of your compiler, quite properly and responsibly, take it
> upon themselves to warn you that you should not use gets(). Why are
> you still using it?
Well, fundamentally, the reason he uses it is because its there, and
because the language standard itself continues to endorse the use of
this function. Unfortunately, the compiler, even after warning you,
and with all sorts of comments telling you about it in the man pages,
goes ahead and compiles/links the code. The compiler/linker *could*
simply dump out with an error unless you give it a -unsafe flag or
something like that. I still don't know who exactly is pulling for the
continued support for this function, but they seem to have a lot of
influence over compiler vendors and the standards committee.
The OP sees this linker warning as an annoyance, and wants to make the
annoyance go away. He's lucky in that here are some reponses here
telling him to stop using the function, but on another day he'd just
get a lot of bickering about top-posting, or forgetting to quote a
previous post or quoting too much of one.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Jordan Abel
> Jack Klein wrote:
>> On 23 Dec 2005 20:29:01 -0800, "Lee" <lee...@gmail.com> wrote in
>> comp.lang.c:
>> > Whenever I use the gets() function, the gnu c compiler gives a
>> > warning that it is dangerous to use gets().
>
> Personally, I am waiting for the compiler that implements gets as the
> following:
>
> char * gets (char * s) {
> unlink (__FILE__); /* POSIX */
> return s;
> }
>
> Since it would improve its predictability.
The problem is that, while gets _can_ invoke undefined behavior based
on things the programmer has no control over, it is well-defined as long
as that does not happen - this is the same reason that it's not legal
for an implementation to reject a program using it
webs...@gmail.com
> On 23 Dec 2005 21:53:53 -0800, "nickptar" <nick...@gmail.com> wrote
> in comp.lang.c:
> > Barry Schwarz wrote:
> >
> > > Don't hold your breath. Buffer overflow is not a c language topic.
> >
> > But is well documented elsewhere:
> > http://en.wikipedia.org/wiki/Buffer_overflow
>
> Nothing in Wikipedia can be considered well documented without
> additional credible references.
Uh ... according to a recent independent study, the Encyclopedia
Britanica has only a 33% better error rate than Wikipedia (meaning
Wikipedia has roughly 33% more errors per article than Britanica.) Now
of course, that doesn't mean you should rely solely on Wikipedia, but
what it means is that if you should apply roughly the same degree of
trust to Wikipedia that you would a reasonable encyclopedia (maybe its
as good as Funk & Wagnals :) )
The funny ironic thing about supposed experts who complain about the
accuracy of Wikipedia is that they don't bother to come to the
realization that the degree of correctness of any given Wikipedia
article is actually in their hands. I wonder -- in who's interest is
it to denigrate or attack Wikipedia.
Richard Heathfield
> Jack Klein wrote:
>> On 23 Dec 2005 20:29:01 -0800, "Lee" <lee...@gmail.com> wrote in
>> comp.lang.c:
>> > Whenever I use the gets() function, the gnu c compiler gives a
>> > warning that it is dangerous to use gets().
>
> Personally, I am waiting for the compiler that implements gets as the
> following:
>
> char * gets (char * s) {
> unlink (__FILE__); /* POSIX */
remove(__FILE__); /* ISO */
>> The solution is simple: don't use gets(). Not ever.
>
> Hmmm ... here's a rhetorical question. What is the value of a
> specifying a function in the language definition if you can't even use
> it -- not ever?
None whatsoever. So let's drop it from the language definition.
Mark McIntyre
wrote:
>Uh ... according to a recent independent study, the Encyclopedia
>Britanica has only a 33% better error rate than Wikipedia
If you examine the study rather than news reports on it from seemingly
uninformed journos, you will find that Nature deliberately excluded
articles which might be subject to any contention, disagreement or
debate, ie anything in humanities, much of the science, politics, and
all biography. This eliminates virtually all of Wikipedia I suspect.
And 33% more errors in the articles there is no debate about sounds
pretty dang poor to me. :-)
>The funny ironic thing about supposed experts who complain about the
>accuracy of Wikipedia is that they don't bother to come to the
>realization that the degree of correctness of any given Wikipedia
>article is actually in their hands.
I always love this bullshit argument.
"Someone else wrote lies and/or misinformation but thats not their
fault, its yours for not spending your time fixing it."
Er, no. Its the fault of the person who was too lazy, biassed or
ignorant to get the facts right in the first place, and its the fault
of the maintainers of wikipedia for not applying better editorial
control.
>I wonder -- in who's interest is it to denigrate or attack Wikipedia.
And in whose interest is it to defend it, even when faced with a
glaring failure ?
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Emmanuel Delahaye
> Personally, I am waiting for the compiler that implements gets as the
> following:
>
> char * gets (char * s) {
> unlink (__FILE__); /* POSIX */
Why using an extension when the standard function does exist ?
remove (__FILE__);
> return s;
> }
BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)
--
A+
Emmanuel Delahaye
Richard Heathfield
> webs...@gmail.com a écrit :
>>
>> char * gets (char * s) {
>> unlink (__FILE__); /* POSIX */
>
> Why using an extension when the standard function does exist ?
Good question.
> remove (__FILE__);
>
>> return s;
>> }
>
> BTW, I suppose that you want some [C99] 'inline'. If not, the effect
> would be limited (the implementation file is probably not that close)
Well, in all fairness to websnarf, those foolish enough to use gets() would,
one hopes, tend to be ill-informed students who will be running their
student exercise programs on the very machine on which they are compiling
those programs.
As an educational LART, it's not a terribly bad idea.
webs...@gmail.com
> Emmanuel Delahaye said:
> > webs...@gmail.com a écrit :
> >> char * gets (char * s) {
> >> unlink (__FILE__); /* POSIX */
> >
> > Why using an extension when the standard function does exist ?
I was just unaware of the existence of remove(), but happened to run
across unlink() in some incidental search through my documentation some
time ago. Learn a new thing every day.
> Good question.
>
> > remove (__FILE__);
> >
> >> return s;
> >> }
> >
> > BTW, I suppose that you want some [C99] 'inline'. If not, the effect
> > would be limited (the implementation file is probably not that close)
Right, and if we don't have C99 then we can't force this to work. Oh
what a great standard this language has ... *sigh*. Anyhow, my comment
was really aimed at compiler implementors not general programmers.
> Well, in all fairness to websnarf, those foolish enough to use gets() would,
> one hopes, tend to be ill-informed students who will be running their
> student exercise programs on the very machine on which they are compiling
> those programs.
>
> As an educational LART, it's not a terribly bad idea.
*DING DING DING DING DING!* Give the man a prize.
Randy Howard
(in article
<dok52h$art$1...@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>):
> Emmanuel Delahaye said:
>> BTW, I suppose that you want some [C99] 'inline'. If not, the effect
>> would be limited (the implementation file is probably not that close)
>
> ... those foolish enough to use gets() would,
> one hopes, tend to be ill-informed students who will be running their
> student exercise programs on the very machine on which they are compiling
> those programs.
Possibly, but I wonder how many hits you would find if you could
grep the source on all of sourceforge for gets(). I suspect
it's nonzero, and that represents a tiny portion of the software
out there that could contain it, outside of "student code".
(Yes, I know a lot of what is on sourceforge is student level,
at best)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Keith Thompson
[...]
> Don't hold your breath. Buffer overflow is not a c language topic.
Sure it is, but the discussion ends with the phrase "undefined
behavior".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Joe Wright
> Lee said:
>
>
>>Hi
>>
>> Whenever I use the gets() function, the gnu c compiler gives a
>>warning that it is dangerous to use gets().
>
>
> No, it's the linker that warns you, not the compiler.
>
>
>>Is this due to the possibility of array overflow?
>
>
> Yes.
>
>
>>Is it correct that the program flow can be altered by giving some
>>specific calculated inputs to gets()?
>
>
> Yes.
>
>
>>How could anyone do so once the executable binary have been generated?
>
>
> By overwriting the stack, for example. On a typical machine, the program is
> loaded from disk into memory before execution. During execution, it is
> present in memory. And the thing about memory is that it can be overwritten
> with new values.
>
>
>>I have heard many of the security problems and other bugs are due to
>>array overflows.
>
>
> Quite.
>
fifteen or more years ago and it was evil then. Why are some now just
discovering it is evil? Is anyone listening?
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Richard Heathfield
> Possibly, but I wonder how many hits you would find if you could
> grep the source on all of sourceforge for gets(). I suspect
> it's nonzero, and that represents a tiny portion of the software
> out there that could contain it, outside of "student code".
> (Yes, I know a lot of what is on sourceforge is student level,
> at best)
If a program contains a call to gets(), it is broken. The fact that some
programs contain calls to gets() is not a good argument for continuing to
offer support for gets() in its present form.
If gets() is removed from the library or re-cast as something like
system("format c: /y") or system("rm -rf *") or whatever, then this will
not affect any well-written programs whatsoever. As for those programs it
does affect, we're better off without them.
webs...@gmail.com
> On 24 Dec 2005 09:35:29 -0800, in comp.lang.c , webs...@gmail.com
> wrote:
> >Uh ... according to a recent independent study, the Encyclopedia
> >Britanica has only a 33% better error rate than Wikipedia
>
> If you examine the study rather than news reports on it from seemingly
> uninformed journos, you will find that Nature deliberately excluded
> articles which might be subject to any contention, disagreement or
> debate, ie anything in humanities, much of the science, politics, and
> all biography. This eliminates virtually all of Wikipedia I suspect.
But it would eliminate all of Britanica too by the same reasoning.
Obviously they wanted to pick topics for which they could find real
authorities that could establish absolute truth on the topic. That's a
little hard to do with abortion.
> And 33% more errors in the articles there is no debate about sounds
> pretty dang poor to me. :-)
Well as long as we are going to cite the actual data -- they found an
average of 3 errors per article in Britanica, and 4 in Wikipedia.
Personally I find anything above about 0.001 pretty unacceptable to me,
but if this is the best standard we have, then I just see it as a wash
-- Britanica and Wikipedia are roughly the same, and you need to go
beyond them for any serious research anyways.
As a side note, I've made about a half dozen significant contributions
to Wikipedia myself, and try very hard to steer away from anything that
isn't clearly true or which incorporates my personal bias. So when I
read that story, I was a little saddened to learn that the error rate
is so high (I really don't think my error rate on WikiPedia is anywhere
near that), but equally shocked that Britanica is not better in any way
that seriously matters.
What's poor is that there is an error rate in articles that is greater
than 1 per, let alone as bad as 3 or 4. Is the human race really that
pathetic that technical integrity is beyond our grasp? Britanica is
not relevantly better -- so the problem is not with Wikipedia but with
people's accuracy in general.
> >The funny ironic thing about supposed experts who complain about the
> >accuracy of Wikipedia is that they don't bother to come to the
> >realization that the degree of correctness of any given Wikipedia
> >article is actually in their hands.
>
> I always love this bullshit argument.
> "Someone else wrote lies and/or misinformation but thats not their
> fault, its yours for not spending your time fixing it."
No the problem is that these people spend their time yelling about the
inaccuracies at the top of their lungs instead of being part of the
solution, for which there is an obvious need.
> Er, no. Its the fault of the person who was too lazy, biassed or
> ignorant to get the facts right in the first place, and its the fault
> of the maintainers of wikipedia for not applying better editorial
> control.
This shows ignorance of how Wikipedia works. There *IS* no structured
editorial control outside the contributors themselves. And there is no
*fault* here. If you don't have the patience to be part of the
solution, your standing in decrying its problems are seriously
undermined and IMHO, have no value. You didn't pay for Wikipedia, and
you didn't put in any effort to make it better, and yet you are going
to complain about it rather than either marvelling at just how good it
is considering or helping make it better.
This just seems to me like seeing an deaf old lady trying to cross a
railroad track with a train coming, then pulling up a lawn chair and
saying "Wow, this accident is going to be good!"
> >I wonder -- in who's interest is it to denigrate or attack Wikipedia.
>
> And in whose interest is it to defend it, even when faced with a
> glaring failure ?
Having a universally accessible, amazing large, somewhat accountable,
up to date, and free encyclopedia with an accuracy rate (which I have a
small role in assisting) similar to commercial offerings? See, unlike
some people, I actually see a lot of *value* in Wikipedia -- and I
think a lot of people do. If the effort I put into it is mirrored by
others, then it will mean that I should expect that level of content
and accuracy of the thing to be extremely high.
As an aside, I recently looked up information about Sucralose and
Aspartame -- I was just looking up basic information, and as
comparison, I was also googled for information on those two things.
The whole business about stability, how they are mixed with other sugar
substitutes, and the process by which they are made, and the safety
arguments for each comes across is a very clear and structured way in
the Wikipedia articles. I *learned* something from Wikipedia that I
just couldn't get from google searches, and that aren't going to be in
obsolete versions of Britanica, or sparse resources like Microsoft's
Encarta (the last two, which nobody seems to criticize with anywhere
near the volume we're seeing Wikipedia criticism.) Now if I want
*real* information about those sugar substitutes, I am going to have to
collect data myself from various FDA and equivalents from other
countries (since I don't really trust the american one.) That's a bit
of a research project considering I just wanted basic information.
So you can count me among the defenders.
Richard Heathfield
> When was it that use of gets() became widely known as evil?
1988, I think.
> Is anyone listening?
Alas, no.
Randy Howard
(in article
> Randy Howard said:
>
>> Possibly, but I wonder how many hits you would find if you could
>> grep the source on all of sourceforge for gets(). I suspect
>> it's nonzero, and that represents a tiny portion of the software
>> out there that could contain it, outside of "student code".
>> (Yes, I know a lot of what is on sourceforge is student level,
>> at best)
>
> If a program contains a call to gets(), it is broken. The fact that some
> programs contain calls to gets() is not a good argument for continuing to
> offer support for gets() in its present form.
Which is why I wasn't arguing for continued support. I was
simply commenting about the idea that it was useful for teaching
purposes, which I'm not sold on.
> If gets() is removed from the library or re-cast as something like
> system("format c: /y") or system("rm -rf *") or whatever, then this will
> not affect any well-written programs whatsoever.
Gee, that's likely.
> As for those programs it does affect, we're better off without them.
Agreed.
Randy Howard
(in article <p4udnYzyxZq4NjDe...@comcast.com>):
> When was it that use of gets() became widely known as evil? I started C
> fifteen or more years ago and it was evil then.
Sounds about right.
> Why are some now just discovering it is evil? Is anyone listening?
For the same reason that "news" is considered recurring daily if
not hourly discussion of some missing girl in the caribbean six
months after it happened.
Tech "news" is limited to the latest cool video card for gaming.
What we need is a "slashdot" for actual programmers, rather
than a version aimed at those that wish to pretend to be
technical by discussing the latest gadget trends.
Usenet used to serve that purpose, but a very small percentage
of the tech community is involved in it today.
Jordan Abel
> Joe Wright said:
>
>> When was it that use of gets() became widely known as evil?
>
> 1988, I think.
Why did it make it into the standard, then? Other things from the base
document [IIRC for the library it was the "/usr/group" proto-posix
standard] didn't make it in, or were changed
Jordan Abel
> Richard Heathfield wrote
> (in article
> <dokb02$7l6$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>):
>
>> Randy Howard said:
>>
>>> Possibly, but I wonder how many hits you would find if you could
>>> grep the source on all of sourceforge for gets(). I suspect
>>> it's nonzero, and that represents a tiny portion of the software
>>> out there that could contain it, outside of "student code".
>>> (Yes, I know a lot of what is on sourceforge is student level,
>>> at best)
>>
>> If a program contains a call to gets(), it is broken. The fact that some
>> programs contain calls to gets() is not a good argument for continuing to
>> offer support for gets() in its present form.
>
> Which is why I wasn't arguing for continued support. I was
> simply commenting about the idea that it was useful for teaching
> purposes, which I'm not sold on.
>
>> If gets() is removed from the library or re-cast as something like
>> system("format c: /y") or system("rm -rf *") or whatever, then this will
>> not affect any well-written programs whatsoever.
>
> Gee, that's likely.
A more likely change is to add a required diagnostic [some
implementations already provide such a diagnostic] and perhaps to allow
such programs to fail to translate.
Richard Heathfield
> I was
> simply commenting about the idea that it was useful for teaching
> purposes, which I'm not sold on.
Nobody has suggested that gets() is useful for teaching purposes, as far as
I'm aware. What somebody did suggest was that an overtly destructive
implementation of gets() would have educational value. I think it's called
aversion therapy.
Mark McIntyre
Most likely, lots of existing code using it already.
Mark McIntyre
wrote:
>But it would eliminate all of Britanica too by the same reasoning.
Incorrect: It would eliminate 50% less of Britannica.
>Obviously they wanted to pick topics for which they could find real
>authorities that could establish absolute truth on the topic. That's a
>little hard to do with abortion.
Perhaps you should actually read the Nature article, instead of
guessing.
>-- Britanica and Wikipedia are roughly the same, and you need to go
>beyond them for any serious research anyways.
33% is significantly outside the statistical level of 'sameness' for
the article population they examined. Do you have any idea about
stats?
>> I always love this bullshit argument.
>> "Someone else wrote lies and/or misinformation but thats not their
>> fault, its yours for not spending your time fixing it."
>
>No the problem is that these people spend their time yelling
No, this isn't the problem. Trying to blame the people who spot the
errors is classic defensive behaviour of someone who knows they're
wrong by the way,
>about the
>inaccuracies at the top of their lungs instead of being part of the
>solution, for which there is an obvious need.
I recommend you read the Register's excellent series of articles on
exactly what happens when one actually /does/ try to correct glaring
errors, omissions and falsehoods.
>> Er, no. Its the fault of the person who was too lazy, biassed or
>> ignorant to get the facts right in the first place, and its the fault
>> of the maintainers of wikipedia for not applying better editorial
>> control.
>
>This shows ignorance of how Wikipedia works. There *IS* no structured
>editorial control outside the contributors themselves.
This is precisely my point. There is no editorial control, so there
is nothing, nothing at all, to prevent complete lies, falsehoods,
misunderstandings and other mistakes.
>If you don't have the patience to be part of the
>solution,
Ah. I didn't realise I was talking to a cretinous utopian "the web is
god" lunatic.
>So you can count me among the defenders.
I pity you.
Gordon Burditt
>possibility of array overflow?
Yes, plus the inability to do ANYTHING to prevent it until
it's too late.
>Is it correct that the program flow can
>be altered by giving some specific calculated inputs to gets()?
Chances are, you can alter the program flow by simply giving gets()
a sufficiently long line without calculating much of anything. This
is particularly true if the input buffer for gets() is an auto
character array. (Although this is system-specific, it is likely
to amount to "scribbling on the return address in the stack frame",
causing a branch to, err, somewhere) The program will likely just
crash rather than send out tons of Viagra ads for you, but often
that's enough to do damage.
>How
>could anyone do so once the executable binary have been generated? I
Why don't you ask the FBI Computer Task Force?
>have heard many of the security problems and other bugs are due to
>array overflows.
Gordon L. Burditt
Jack Klein
<regn...@btinternet.com> wrote in comp.lang.c:
> "Jack Klein" <jack...@spamcop.net> wrote
> >
> > Nothing in Wikipedia can be considered well documented without
> > additional credible references.
> >
> <OT>
> That's what crusty academics say because a new competitor has come along. Of
> course they want people to rely on peer-reviewed literature where they are
> the peers.
And your sentence, above, is what many uncredentialed individuals say
when they want their (opinions, theories, etc.) given full weight
without the necessity of making the effort to obtain the credentials.
Note that I am not saying this is so in your case, nor am I attempting
to insult you.
Quite a few problems have been documented with Wikipedia, several just
recently. One of the real problems with Wikipedia, mostly absent from
formal peer-review literature, is the anonymity and lack of
accountability of the contributors.
> In fact something like 50% of scientific papers make conclusions which are
> later refuted or challenged by further papers. (read Iohannis for a
> peer-reviewed take on the subject).
> No medium written by humans can guarantee complete accuracy, freedom form
> bias, etc. Wikipedia is no different from any other source.
Wikipedia is very much different from many other sources. I made no
claims whatsoever about its quality, accuracy, or freedom from bias. I
merely responded to a line in an earlier post, which you snipped,
where a poster claimed that something was "well documented" followed
by a link to Wikipedia.
Based on recent well publicized events, I maintain that existence of a
Wikipedia article, by itself, does not guarantee that the atricle's
subject is well documented.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Randy Howard
(in article
> Randy Howard said:
>
>> I was
>> simply commenting about the idea that it was useful for teaching
>> purposes, which I'm not sold on.
>
> Nobody has suggested that gets() is useful for teaching purposes, as far as
> I'm aware. What somebody did suggest was that an overtly destructive
> implementation of gets() would have educational value. I think it's called
> aversion therapy.
Ahh. I misunderstood then.
Malcolm
"Jack Klein" <jack...@spamcop.net> wrote
>> That's what crusty academics say because a new competitor has come along.
>> Of
>> course they want people to rely on peer-reviewed literature where they
>> are
>> the peers.
>
> And your sentence, above, is what many uncredentialed individuals say
> when they want their (opinions, theories, etc.) given full weight
> without the necessity of making the effort to obtain the credentials.
> Note that I am not saying this is so in your case, nor am I attempting
> to insult you.
>
fact is that the student obtains his knowledge from Wikipedia, because if
you want go from knowing nothing about a topic to having some level of
background, the easiest and legitimate way is to type "Jacobi decomposition"
into Wikipedia.
>
> Quite a few problems have been documented with Wikipedia, several just
> recently. One of the real problems with Wikipedia, mostly absent from
> formal peer-review literature, is the anonymity and lack of
> accountability of the contributors.
>
>
> Wikipedia is very much different from many other sources. I made no
> claims whatsoever about its quality, accuracy, or freedom from bias. I
> merely responded to a line in an earlier post, which you snipped,
> where a poster claimed that something was "well documented" followed
> by a link to Wikipedia.
>
> Based on recent well publicized events, I maintain that existence of a
> Wikipedia article, by itself, does not guarantee that the atricle's
> subject is well documented.
>
information. It must not be dismissed, but I agree that one mustn't accept
everything written as authoritative.
Giannis Papadopoulos
> "Jack Klein" <jack...@spamcop.net> wrote
>
>>>That's what crusty academics say because a new competitor has come along.
>>>Of
>>>course they want people to rely on peer-reviewed literature where they
>>>are
>>>the peers.
>>
>>And your sentence, above, is what many uncredentialed individuals say
>>when they want their (opinions, theories, etc.) given full weight
>>without the necessity of making the effort to obtain the credentials.
>>Note that I am not saying this is so in your case, nor am I attempting
>>to insult you.
>>
>
> There's a fuss at our university about students referencing Wikipedia. The
> fact is that the student obtains his knowledge from Wikipedia, because if
> you want go from knowing nothing about a topic to having some level of
> background, the easiest and legitimate way is to type "Jacobi decomposition"
> into Wikipedia.
Yes, I have found it very useful to make a jump start on a new subject.
And I may reference it, but I cannot see how can any paper or anything
else rely entirely on wikipedia.
Maybe in some years, when Google or someone else will collect all human
written knowledge and research and post it on the Internet, wikipedia
may act as a central "knowledge hub"...
webs...@gmail.com
> "Jack Klein" <jack...@spamcop.net> wrote
> >> That's what crusty academics say because a new competitor has come along.
> >> Of course they want people to rely on peer-reviewed literature where they
> >> are the peers.
> >
> > And your sentence, above, is what many uncredentialed individuals say
> > when they want their (opinions, theories, etc.) given full weight
> > without the necessity of making the effort to obtain the credentials.
> > Note that I am not saying this is so in your case, nor am I attempting
> > to insult you.
>
> There's a fuss at our university about students referencing Wikipedia. The
> fact is that the student obtains his knowledge from Wikipedia, because if
> you want go from knowing nothing about a topic to having some level of
> background, the easiest and legitimate way is to type "Jacobi decomposition"
> into Wikipedia.
But its not just that. You can also get up to date information that is
directly integrated into articles even of a historical nature (for
example if a FOIA request reveals some activity by the CIA from 50
years ago, and this has a previously unrealized perspective on history,
or whatever.) You can also get information from corporate insiders, or
from people who otherwise can distill really convoluted information
into simple short articles that would otherwise not find a normal
mainstream vehicle for being revealed. (Like details about Sucralose
and Aspartame.)
> > Quite a few problems have been documented with Wikipedia, several just
> > recently. One of the real problems with Wikipedia, mostly absent from
> > formal peer-review literature, is the anonymity and lack of
> > accountability of the contributors.
>
> There is a case for ending the tradition of anonymity.
Yeah, and of course the people who are crying a river about it, don't
bother to notice that things *ARE* being done about this. (Only
registered users can author new articles, certain articles are blocked
from being editted except by credible wikipedians, etc.)
> > Wikipedia is very much different from many other sources. I made no
> > claims whatsoever about its quality, accuracy, or freedom from bias. I
> > merely responded to a line in an earlier post, which you snipped,
> > where a poster claimed that something was "well documented" followed
> > by a link to Wikipedia.
> >
> > Based on recent well publicized events, I maintain that existence of a
> > Wikipedia article, by itself, does not guarantee that the atricle's
> > subject is well documented.
>
> It's a new medium. It has its problems. So too do all other sources of
> information. It must not be dismissed, but I agree that one mustn't accept
> everything written as authoritative.
And that's the line of reasoning that just doesn't have play with the
naysayers. And I don't know why. This is the *OBVIOUS* most well
reasoned position to take -- its new, and its got growing pains, and is
otherwise quite remarkable given this situation. "A new technology is
not perfect" -- wow what impressive and deep criticism.
The vicious attacks on Wikipedia in the recent press about it are one
sided and completely out of proportion. Its as if there is some other
adgenda at work here but I don't quite understand it. Who would have
some innate hatred of the concept a large free and pervasive
encyclopedia whose quality is remarkable given the premise of being
built by random contributors? Is this campaign being waged by
Britanica? By historians or other intellectuals who don't like being
second guessed with a Wikipedia search? The news media who don't like
public dissemination of inconvenient truths and perspective to get in
the way of their editorial spin? I dunno -- those all seems a bit on
the conspiratorial side, but there's no denying the existence of a
concerted campaign against Wikipedia.
Richard Heathfield
> On 24 Dec 2005 12:30:16 -0800, in comp.lang.c , webs...@gmail.com
> wrote:
>
>>This shows ignorance of how Wikipedia works. There *IS* no structured
>>editorial control outside the contributors themselves.
>
> This is precisely my point. There is no editorial control, so there
> is nothing, nothing at all, to prevent complete lies, falsehoods,
> misunderstandings and other mistakes.
Or even simple partisanship. Wikipedia shows considerable dislike for C, but
is very positive about, say, C++, Python, and Lisp.
Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did not
honour this tradition. Not sure why - for heaven's sake, it's only a
programming language! But take a look, and you'll see a "criticisms"
section - which is not something I noticed in the C++, Python or Lisp
sections. Does this mean those languages are beyond criticism? Or does it
simply mean the Wikids don't understand C very well?
Richard Heathfield
> The vicious attacks on Wikipedia in the recent press about it are one
> sided and completely out of proportion.
Who cares? What would the press know about it?
> Its as if there is some other
> adgenda at work here but I don't quite understand it.
I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
written by someone who doesn't know C well enough to use it properly.
The Wikipedia attitude to C is like that of an amateur cook railing against
the dangers of carving knives, and recommending butter knives for all your
carving needs.
I also read some of the Wiki articles on other languages - C++, Python,
Lisp. No such anti-language sentiment there.
From a comp.lang.c perspective, then, Wikipedia sucks.
Jordan Abel
> webs...@gmail.com said:
>
>> The vicious attacks on Wikipedia in the recent press about it are one
>> sided and completely out of proportion.
>
> Who cares? What would the press know about it?
>
>> Its as if there is some other
>> adgenda at work here but I don't quite understand it.
>
> I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
> written by someone who doesn't know C well enough to use it properly.
>
> The Wikipedia attitude to C is like that of an amateur cook railing against
> the dangers of carving knives, and recommending butter knives for all your
> carving needs.
>
> I also read some of the Wiki articles on other languages - C++, Python,
> Lisp. No such anti-language sentiment there.
>
> From a comp.lang.c perspective, then, Wikipedia sucks.
So edit it to make it a more neutral point of view.
Joe Wright
> Mark McIntyre said:
>
>
>>On 24 Dec 2005 12:30:16 -0800, in comp.lang.c , webs...@gmail.com
>>wrote:
>>
>>
>>>This shows ignorance of how Wikipedia works. There *IS* no structured
>>>editorial control outside the contributors themselves.
>>
>>This is precisely my point. There is no editorial control, so there
>>is nothing, nothing at all, to prevent complete lies, falsehoods,
>>misunderstandings and other mistakes.
>
>
> Or even simple partisanship. Wikipedia shows considerable dislike for C, but
> is very positive about, say, C++, Python, and Lisp.
>
> Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did not
> honour this tradition. Not sure why - for heaven's sake, it's only a
> programming language! But take a look, and you'll see a "criticisms"
> section - which is not something I noticed in the C++, Python or Lisp
> sections. Does this mean those languages are beyond criticism? Or does it
> simply mean the Wikids don't understand C very well?
>
have credentials enough to be accepted by Wiki I'm sure. And you'd be
good at it, it's only writing after all. Not reading. :-)
Richard Heathfield
> Richard Heathfield wrote:
>>
>> Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did
>> not honour this tradition. Not sure why - for heaven's sake, it's only a
>> programming language! But take a look, and you'll see a "criticisms"
>> section - which is not something I noticed in the C++, Python or Lisp
>> sections. Does this mean those languages are beyond criticism? Or does it
>> simply mean the Wikids don't understand C very well?
>>
> Clearly an opportunity for you Richard, to set the record straight.
Don't tempt me.
> You have credentials enough to be accepted by Wiki I'm sure.
That would change as soon as I started deleting entire swathes of useless
material and told them to read a decent book about C and spend a few years
writing it properly before expressing an opinion on it.
those who know me have no need of my name
>On 2005-12-24, Richard Heathfield <inv...@invalid.invalid> wrote:
>> Joe Wright said:
>>> When was it that use of gets() became widely known as evil?
>>
>> 1988, I think.
>
>Why did it make it into the standard, then?
because it was in wide use. see the rationale if you would like more
words.
--
a signature
S.Tobias
> webs...@gmail.com a écrit :
>> Personally, I am waiting for the compiler that implements gets as the
>> following:
>>
>> char * gets (char * s) {
...
> remove (__FILE__);
>
>> return s;
>> }
>
> BTW, I suppose that you want some [C99] 'inline'. If not, the effect
> would be limited (the implementation file is probably not that close)
>
I don't think `inline' would help anything. Inline functions are
not expanded the same way as macros are, and `__FILE__' in above
code (after adding `inline') should still resolve to the name of
the implementation file.
#define gets(s) (remove(__FILE__), gets(s))
--
Stan Tobias
mailx `echo si...@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
...
>Or even simple partisanship. Wikipedia shows considerable dislike for C, but
>is very positive about, say, C++, Python, and Lisp.
I don't see where you get this. I read the Wikipedia entry for C, and,
yes, it includes a Critcism section. I consider the article quite
balanced, and it sounds like you are saying that any criticism is bad.
This is the position one expects from defenders of a faith. A "you're
either with us or against us" mentality.
I think we all agree that C has its problems. That, first of all, any
language that was designed to be "portable assembler" is going to have
problems in the safety department. And second, that the existence of all
this "UB" in the language definition (I.e., that which is the primary
subject of this newsgroup) is not a Good Thing. Necessary, of course,
given what C is, but not in any sense desirable in the abstract.
I think it is entirely fair and reasonable (aye, in fact to not do so would
be irresponsible) to warn potential newcomers to the language of its
dangers.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
...
>material and told them to read a decent book about C and spend a few years
>writing it properly before expressing an opinion on it.
But that's precisely the problem - most (counted by sheer numbers - i.e.,
one human being, one vote) people who use C don't and never will use it
correctly. I think it is for them that the Wikipedia article is written.
Then, of course, there is also the universal phenomenon that whenever the
media (media of any nature, and yes, in today's world, that includes
Wikipedia) reports on *anything* that you (rhetorical "you") knows anything
about, they get it all wrong. Or, more precisely, all you see are the
errors. Just something we all have to live with.
Kenny McCormack
Joe Wright <joeww...@comcast.net> wrote:
...
>When was it that use of gets() became widely known as evil? I started C
Ah, I see. You are a newcomer to the language.
Kenny McCormack
Gordon Burditt <gordon...@burditt.org> wrote:
...
>>How
>>could anyone do so once the executable binary have been generated? I
>
>Why don't you ask the FBI Computer Task Force?
Google for "Smashing the stack for fun and profit".
Malcolm
> That would change as soon as I started deleting entire swathes of useless
> material and told them to read a decent book about C and spend a few years
> writing it properly before expressing an opinion on it.
>
the formal method is so compex and burdensome that it is easier for a human
to write correct code first time than to follow the method in all its
intricacies).
Some supporter of formal methods said that I didn't have the experience to
make such an assertion.
I replied that I had been on a six month training course on formal methods.
"Ha," said the supporter of formal methods, "the people who devise these
methods have often spent twenty years developing them. And you are rejecting
them on the basis of a six month course."
The problem with that argument is that the number of six month courses I can
go on is strictly limited. I wouldn't say I am necessarily right about
formal methods, but I have a great deal of experience in programming. If
someone cannot convince me of the value of his approach in six months, then
I must have a powerful and qualified case that the approach is not, in fact,
valuable.
Richard Heathfield
> In article <doo0fa$e3h$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
> Richard Heathfield <inv...@invalid.invalid> wrote:
> ...
>>Or even simple partisanship. Wikipedia shows considerable dislike for C,
>>but is very positive about, say, C++, Python, and Lisp.
>
> I don't see where you get this. I read the Wikipedia entry for C, and,
> yes, it includes a Critcism section. I consider the article quite
> balanced, and it sounds like you are saying that any criticism is bad.
Not at all. But if you're going to have a "criticisms" section for one
language, why not for all of them? Are all languages flawless, perfect, and
beyond reproach, except for C and Pascal?
> This is the position one expects from defenders of a faith. A "you're
> either with us or against us" mentality.
Nonsense. I'm not asking for partiality. I'm asking for impartiality.
> I think we all agree that C has its problems.
And C++ doesn't?
> That, first of all, any
> language that was designed to be "portable assembler" is going to have
> problems in the safety department. And second, that the existence of all
> this "UB" in the language definition (I.e., that which is the primary
> subject of this newsgroup) is not a Good Thing. Necessary, of course,
> given what C is, but not in any sense desirable in the abstract.
Of course it's desirable. It gives the C programmer and implementation lots
of scope for inventiveness in a tight spot. Take, for example, this code:
void printat(const char *s, int x, int y)
{
unsigned char *p = (unsigned char *)0xb8000000UL + 160 * y + 2 * x;
int c = (g_fg << 4) | g_bg;
while(*s)
{
*p++ = *s++;
*p++ = c;
}
}
Extremely badly-behaved code, utterly undefined behaviour, but it works just
fine on the right platform, and is extremely quick compared to the
alternatives on that platform. For the Standard to mandate the behaviour of
this code would be meaningless, and for the Standard to forbid this code
would be overly restrictive. Making the behaviour undefined makes perfect
sense. Basically, it's saying "weeeelllll, okay, if that's what you want to
do, I won't try to stop you", which is fine by me.
> I think it is entirely fair and reasonable (aye, in fact to not do so
> would be irresponsible) to warn potential newcomers to the language of its
> dangers.
That is true of all programming languages of any power, so now you are
effectively suggesting that Wikipedia is irresponsibly lax in not warning
of the dangers of other languages.
Richard Heathfield
> "Ha," said the supporter of formal methods, "the people who devise these
> methods have often spent twenty years developing them. And you are
> rejecting them on the basis of a six month course."
And you had every right to choose not to use formal methods, on the strength
of your six month course spent learning about them. What your six month
course does /not/ give you is the credentials necessary for writing an
authoritative encyclopaedia article criticising formal methods.
Grumble
> Whenever I use the gets() function, the gnu c compiler gives a
> warning that it is dangerous to use gets(). Is this due to the
> be altered by giving some specific calculated inputs to gets()? How
> could anyone do so once the executable binary have been generated? I
> array overflows.
Malcolm
"Richard Heathfield" <inv...@invalid.invalid> wrote
> Malcolm said:
>
>> "Ha," said the supporter of formal methods, "the people who devise these
>> methods have often spent twenty years developing them. And you are
>> rejecting them on the basis of a six month course."
>
> And you had every right to choose not to use formal methods, on the
> strength
> of your six month course spent learning about them. What your six month
> course does /not/ give you is the credentials necessary for writing an
> authoritative encyclopaedia article criticising formal methods.
>
developing formal methods, and I conclude that I have basically wasted my
time and they cannot generally improve productivity or error-rate".
Not impossible or unherad of, but rare.
Richard Heathfield
> "Richard Heathfield" <inv...@invalid.invalid> wrote
>>
>> And you had every right to choose not to use formal methods, on the
>> strength
>> of your six month course spent learning about them. What your six month
>> course does /not/ give you is the credentials necessary for writing an
>> authoritative encyclopaedia article criticising formal methods.
>>
> It would be rare for someone to say "I have spent twenty years studying
> and developing formal methods, and I conclude that I have basically wasted
> my time and they cannot generally improve productivity or error-rate".
> Not impossible or unherad of, but rare.
Someone who has spent 20 years studying and developing a discipline is
indeed likely to look favourably upon it; but he or she will also know a
great deal about it. And that's not a bad place from which to write an
encyclopaedia article, in many circumstances. (Not all; I did think of a
few counter-examples to this!) Certainly a position of relative ignorance
is a /bad/ place from which to write an encyclopaedia article.
Let's take one or two of the Wiki criticisms and look at them more closely:
"In other words, C permits many operations that are generally not
desirable".
So what? Just because Mr Generally doesn't want this particular operation,
it doesn't mean /I/ don't want it or /you/ don't want it. Good for C!
"many simple errors made by a programmer are not detected by the compiler or
even when they occur at runtime."
But programmers tend to make these errors less and less as they gain
knowledge of and experience with C, and so this is a diminishing problem.
If they're bright, the programmers will in any case learn from other
programmers' experiences rather than their own. So this really isn't as big
a problem as it is made to sound.
"One problem with C is that automatically and dynamically allocated objects
are not initialized; they initially have whatever value is present in the
memory space they are assigned."
That isn't a problem at all! It's common sense that the bits in a space
aren't the bits you want until you set them to be the bits you want.
Setting them arbitrarily to zero as a matter of language policy is just a
pointless intermediate step. If /you/ want a given object to have a value
if 0, C makes that easy to do: T obj = {0};
"Another common problem is that heap memory cannot be reused until it is
explicitly released by the programmer with free()".
That's simply not true. As long as you have a pointer to it, you can and may
keep on using it. And if you don't, you mustn't. The article writer's
answer to this tiny housekeeping matter is automatic garbage collection,
which has a whole bundle of its own issues.
"Pointers are one primary source of danger; because they are unchecked, a
pointer can be made to point to any object of any type, including code, and
then written to, causing unpredictable effects."
Actually, you have to be fighting the type system if you want to get a
pointer of any object type to point to something else. For void *, sure,
but void * has redeeming features which make it worth keeping. I doubt
whether any experienced C programmer really considers this to be a problem.
"Although C has native support for static arrays, it does not verify that
array indexes are valid (bounds checking). For example, one can write to
the sixth element of an array with five elements, yielding generally
undesirable results. This is called a buffer overflow. This has been
notorious as the source of a number of security problems in C-based
programs."
Absolutely true. And if you put morons into Mack trucks, the accident rate
for Macks will go up. Put those morons into Mercs, and the accident rate
for Mercs will climb. Now set those morons to writing C code, and look what
happens to the accident rate for C programs.
Buffer overflow is a known and very minor problem. The reason it's a minor
problem is this: it's a simple, easy-to-understand problem. It's not always
easy to understand how it can be exploited, but that's irrelevant. The
weakness itself is simple, and simply avoided. This is like saying "if you
go walking on the motorway, you might get killed; DON'T WALK ON THE
MOTORWAY". People still go walking on the motorway, and people still get
killed doing so. That is not the fault of the motorway.
Incidentally, the article was very complimentary about "Numerical Recipes in
C" for its innovative approach to arrays before I corrected it a few weeks
or months ago (along with one or two other minor corrections I had made as
a prelude to an overhaul, which I abandoned when I found that my
corrections had been edited!). I pointed out that the Numerical Recipes
"solution" isn't a solution at all, being based on utter ignorance of the
rules of C - but that's been modded down to "there is also a solution based
on negative addressing". Stupid stupid stupid.
Well, I could go on to address the other crits if I could be bothered. Let
the Wikids put the above right first. At present, I cannot recommend the
Wiki's C article to anyone. It is, quite simply, riddled with wrongs.
James Dow Allen
Jack Klein wrote:
> The solution is simple: don't use gets(). Not ever.
I suppose my presence in these c.l.c dialogs is a form of masochism but
...
I use gets() everyday! I think I get the "dangerous" message
from almost every make I do! Frankly, if I used a gets() alternative
to avoid the "danger" I'd probably end up using a strcpy()
with the same danger!
You don't need to URL me to the "dangerous" explanation: I used
to design exploits myself. But the fact is, most of the programs I
write
are not for distribution and are run only on my personal machine,
usually with an impermeable firewall. Who's going to exploit me?
My alter ego? My 10-year old daughter? The input to my gets()
is coming from a file I or my software created, and which has
frequent line-feeds. The buffer into which I gets() is ten times
as big as necessary. If one of my data files gets corrupted,
diagnosing
the gets() overrun would be the least of my worries.
I'll agree that such coding should be avoided in programs with
unpredictable
input, but there are *lots* and *lots* of code fragments that suffer
from the same "danger" as gets(), so to me the suggestion that gets()
specifically be barred by the compiler seems like a joke. Or do you
think strcpy() should be barred also?
Glad to help,
James
Richard Heathfield
> I'll agree that such coding should be avoided in programs with
> unpredictable input,
And therefore the only safe advice here in clc is "don't use gets()", since
we can never predict what input will be provided to it.
> but there are *lots* and *lots* of code fragments that suffer
> from the same "danger" as gets(), so to me the suggestion that gets()
> specifically be barred by the compiler seems like a joke. Or do you
> think strcpy() should be barred also?
The thing about gets() is that you can't code to make it robust, in a way
that you can with strcpy(). You shouldn't ever, ever, EVER call the
strcpy() function until you have first checked that your target buffer is
big enough to receive the input string. You see? You can hack up a check to
make a strcpy() call safe. You can't do the same for gets(), because to do
so would involve seeing into the future.
Giannis Papadopoulos
Although it may seem that it is ok to use such code for personal apps,
it is not a very good idea overall.
And I think it is a good practice to write robust and safe programs,
even for personal use.
Eric Sosman
>
> I use gets() everyday! [...]
> [...] The input to my gets()
> is coming from a file I or my software created, and which has
> frequent line-feeds. The buffer into which I gets() is ten times
Semi-rhetorical question: If you're sure that the
file's lines are of reasonable length, why make the
buffer ten times larger than needed? Pascal's Wager?
--
Eric Sosman
eso...@acm-dot-org.invalid
Richard Heathfield
Something like that, I guess.
For the record, if I'm cranking out some one-off code, I use oversized
buffers too - much, much larger than I could possibly need - but I still
use fgets rather than gets.
(If I'm not sure that the code is going to be discarded fairly soon, I would
not use fgets either; instead, I'd use something that can handle
arbitrarily long lines.)
Kenny McCormack
Rob Adams
> Joe Wright said:
>>When was it that use of gets() became widely known as evil?
>
For the benefit of those who weren't working (or even born?) then,
November 2, 1988, to be precise.
http://en.wikipedia.org/wiki/Morris_worm
And
Malcolm
"Richard Heathfield" <inv...@invalid.invalid> wrote
> Well, I could go on to address the other crits if I could be bothered. Let
> the Wikids put the above right first. At present, I cannot recommend the
> Wiki's C article to anyone. It is, quite simply, riddled with wrongs.
>
The basic problem is that the writer doesn't understand that his criticisms
are mostly the inevitable consequence of having direct memory addressing,
and not allowing lengthy operations like garbage collection.
It is a bit like criticising a petrol car for having a gearbox. Gears are a
nuisance, they break down, they waste energy. Electric cars don't need them.
But electric cars have other disadvantages, and it is virtutally impossible
to build a petrol engine that doesn't need gears.
Kenny McCormack
I think both of you guys are too emotionally invested in this.
The article was just making the point that C/C++ (*) is not a baby-safe
language. There's nothing wrong with that, it just means that C/C++ are
like chainsaws - very dangerous in inept hands. And, industry wants safe
langauges, that inept, low skilled labor can use.
Anecdotally, I will say that when I learned my first assembly language (a
couple of million years ago), the first thing that really shocked me was
the fact that it wasn't baby-safe - that I could do totally undefined
things and get totally obscure error messages from doing so. I think
that's the primary difference between languages like C/C++ (and, as it
turns out, many dialects of Pascal as well [*]) and "user-proof" languages
like BASIC - that is, that you can get obscure (and basically useless)
error messages like "Segmentation Violation", when you do something stupid.
(*) Yes, I know it is doctrine around here that C and C++ are two different
languages and that it is heresy to speak of them as a slashed entity like
this. But C++ has all the same "non-user-proof" features that C has, and
so, I think, for the sake of this thread, we can treat them thusly (as
a "slashed entity"). In particular, I know that Richard was trying to say
that Wikipedia was being unfair to C and biased towards C++, but I think we
all understand that most of the criticisms of C apply equally well to C++.
[*] Again, lest you think I am favoring Pascal at C's expense.
Richard Heathfield
> I think both of you guys are too emotionally invested in this.
There's nothing particularly emotional about it. The Wiki article is just
plain wrong.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Kenny McCormack said:
>
>> I think both of you guys are too emotionally invested in this.
>
>There's nothing particularly emotional about it. The Wiki article is just
>plain wrong.
No, it isn't. But thank you for playing our game.
Richard Heathfield
Yes, it is. (etc etc)
And if you browse around the Wiki for a while, you'll find other articles on
C, each of which has their own little collection of mistakes.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Kenny McCormack said:
>
>> In article <dov6ig$mg0$1...@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
>> Richard Heathfield <inv...@invalid.invalid> wrote:
>>>Kenny McCormack said:
>>>
>>>> I think both of you guys are too emotionally invested in this.
>>>
>>>There's nothing particularly emotional about it. The Wiki article is just
>>>plain wrong.
>>
>> No, it isn't.
>
>Yes, it is. (etc etc)
>
>And if you browse around the Wiki for a while, you'll find other articles on
>C, each of which has their own little collection of mistakes.
I suspect you didn't read my other post, in which I explain at some length,
the context in which the Wiki article was written. Once you do that,
you'll understand.
Jordan Abel
> Kenny McCormack said:
>
>> In article <dov6ig$mg0$1...@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
>> Richard Heathfield <inv...@invalid.invalid> wrote:
>>>Kenny McCormack said:
>>>
>>>> I think both of you guys are too emotionally invested in this.
>>>
>>>There's nothing particularly emotional about it. The Wiki article is just
>>>plain wrong.
>>
>> No, it isn't.
>
> Yes, it is. (etc etc)
>
> And if you browse around the Wiki for a while, you'll find other articles on
> C, each of which has their own little collection of mistakes.
Such as? (Yes, he's a troll, but you haven't given any specific examples
of facts claimed that are false, and the article really doesn't look to
me as bad as you claim it is)
Richard Bos
Programming is not a game. It may surprise you, but occasionally there
actually _are_ lives at stake.
Wikipedia _is_ a game. That is basically the whole problem.
Richard
Walter Roberson
Kenny McCormack <gaz...@interaccess.com> wrote:
>The article was just making the point that C/C++ (*) is not a baby-safe
>language. There's nothing wrong with that, it just means that C/C++ are
>like chainsaws - very dangerous in inept hands. And, industry wants safe
>langauges, that inept, low skilled labor can use.
>I think
>that's the primary difference between languages like C/C++ (and, as it
>turns out, many dialects of Pascal as well [*]) and "user-proof" languages
>like BASIC - that is, that you can get obscure (and basically useless)
>error messages like "Segmentation Violation", when you do something stupid.
I haven't looked at any of the modern BASICs, but the BASICs that
I grew up with were not "user-proof". PEEK and POKE were used
for a lot of system dependancies, including a lot of graphics;
and in those days it was common to encode machine language in
DATA statements and then branch to it.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Richard Heathfield
> I suspect you didn't read my other post
That is almost certainly true. If you want to be taken seriously and have
people read your stuff, you need to start acting a bit more seriously. I'm
not about to go hunting for your "other post" in a feed the size of clc, if
it means wading through your trollisms.
Richard Heathfield
>> And if you browse around the Wiki for a while, you'll find other articles
>> on C, each of which has their own little collection of mistakes.
>
> Such as? (Yes, he's a troll, but you haven't given any specific examples
> of facts claimed that are false, and the article really doesn't look to
> me as bad as you claim it is)
I've already pointed out several faults with the lead article.
Observe the first program example on this page:
<http://en.wikipedia.org/wiki/C_syntax>
Further down this page, it gives the following example program:
void setInt(int **p, int n)
{
*p = (int *) malloc(sizeof(int)); // allocate a memory area, using
the pointer given as as a parameter [1]
**p = n;
}
int main(void)
{
int *p; // create a pointer to an integer
setInt(&p, 42); // pass the address of 'p'
return 0;
}
[1] Originally presented as a single line.
If this is C90 code, count the bugs.
If it's C99 code instead, count the bugs.
Here's their example of a scanf call:
int x;
scanf("%d", &x);
Not even my cat would use scanf like that. (The kitten might.)
These are not the only problems, by any means. Now, if you want to find any
more, go look for yourself.
Netocrat
>>>This shows ignorance of how Wikipedia works. There *IS* no structured
>>>editorial control outside the contributors themselves.
Mark McIntyre replied:
>> This is precisely my point. There is no editorial control, so there is
>> nothing, nothing at all, to prevent complete lies, falsehoods,
>> misunderstandings and other mistakes.
<OT> (on-topic info follows)
There is, as on Usenet, the "eternal vigilance" of those citizens
responsible enough to assume it. This simple model protects against a
malicious controlling minority. The Britannica model isn't as good at
that, but it apparently does protect better against corruption by random
malicious/ignorant individuals.
Wikipedia is afaict considering the need for a middle ground, especially
for topics where the honest and informed are not more numerous and more
active than the malicious/ignorant.
</OT>
Richard Heathfield adds:
> [Take a look at the Wikipedia C article], and you'll see a "criticisms"
> section - which is not something I noticed in the C++, Python or Lisp
> sections. Does this mean those languages are beyond criticism? Or does
> it simply mean the Wikids don't understand C very well?
<still OT>
It could also mean that as a knowledgeable C programmer and author, this
is a prime area for exercise of your democratic responsibility for
vigilance against disinformation, and for public debate on correctness.
Elsewhere you presented several (IMO useful) ideas for improving the
article; Wikipedia's policy allows for a neutral "supporters vs critics"
debate, so you needn't view it as all-or-nothing:
<http://tinyurl.com/7uppc>
</OT>
To the topical: the c.l.c community itself can explore the issue of
structured vs open wiki access - the proposed wiki [1] hasn't disappeared,
it's just been worked on quietly for a while.[2]
Software support for the maintenance of an editorial group has been
written and installed.[3] The proposed wiki charter has further
details.[4]
No content other than planning yet exists within the wiki, although there
are clear ideas of what the content will be.[5] To import the K&R2
solutions from Richard Heathfield's unmaintained site (as discussed in a
previous thread), a script has been written.[6]
Now that basic support for moderation exists, feedback, particularly from
regulars, and in particular from Steve Summit as FAQ maintainer and
copyright holder, is solicited:
* do you support the proposed charter and model of a limited editorial
group?
* do you support the proposed content guidelines?
* is it acceptable/desirable to host the comp.lang.c FAQ on such a wiki?
* any other issues/concerns.
If concerted objections arise, likely the wiki will be continued under
an unofficial title, focusing on unique content, until (if at all) the
objections can be resolved. The current wiki permissions are quite open
so that contribution during the planning stage is easier: no edits are
blocked other than anonymous editing and a few selected pages.
The entry point to the wiki is:
<http://clc.flash-gordon.me.uk/wiki/Main_Page>.
[1] Original clc FAQ wiki thread: <http://tinyurl.com/7q3eh>
[2] <http://clc.flash-gordon.me.uk/wiki/Planning:Status>
[3] A decisions and voting extension supports a self-regulating editorial
group with members automatically added and removed by group decision. See
the links immediately above and below for details. The level of
sophistication is presently quite low but development is ongoing.
[4]<http://clc.flash-gordon.me.uk/wiki/Planning:Proposed_Charter>
[5]<http://clc.flash-gordon.me.uk/wiki/Planning:Proposed_Content_Guidelines>
[6] Good-faith efforts are being made to obtain all contributors'
permission prior to running the script. Please respond (email is fine) if
you are on the list linked to here:
<http://clc.flash-gordon.me.uk/wiki/Planning:Missing_Permissions> and wish
to assert or deny permission. Non-response may ultimately be taken as
implicit permission.
Kenny McCormack
Walter Roberson <robe...@ibd.nrc-cnrc.gc.ca> wrote:
...
>I haven't looked at any of the modern BASICs, but the BASICs that
>I grew up with were not "user-proof". PEEK and POKE were used
>for a lot of system dependancies, including a lot of graphics;
>and in those days it was common to encode machine language in
>DATA statements and then branch to it.
I was using BASIC long before there were such things as microcomputers
(aka, PCs). *Real* BASIC on *real* computers (w/o PEEK/POKE/etc) was/is
a baby-proof environment.
And even you can see that if you invoke machine language from within BASIC,
well, then you're not programming in BASIC anymore.
Kenny McCormack
Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
...
(I wrote)
>> No, it isn't. But thank you for playing our game.
>
>Programming is not a game. It may surprise you, but occasionally there
>actually _are_ lives at stake.
Luckily, they don't use anything written by MS.
>Wikipedia _is_ a game. That is basically the whole problem.
Exactly my point. That's why I said "thank you for playing our (Wikipedia)
game."
Thank you ever so much for making my point.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Jordan Abel said:
>
>>> And if you browse around the Wiki for a while, you'll find other articles
>>> on C, each of which has their own little collection of mistakes.
>>
>> Such as? (Yes, he's a troll, but you haven't given any specific examples
>> of facts claimed that are false, and the article really doesn't look to
>> me as bad as you claim it is)
>
>I've already pointed out several faults with the lead article.
>
>Observe the first program example on this page:
>
> <http://en.wikipedia.org/wiki/C_syntax>
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.
(snip a whole bunch of stuff related to the usual CLC "Don't cast the
return value of malloc" and other such trivia)
Richard Heathfield
> 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).
Fine, but that's just another way of saying "Wikipedia is not and never will
be authoritative and does not perceive accuracy as being the primary goal".
> 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.
It's not reasonable to expect them to get stuff right? Okay. That tells us
all we need to know about Wikipedia, I guess.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Kenny McCormack said:
>
>> 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).
>
>Fine, but that's just another way of saying "Wikipedia is not and never will
>be authoritative and does not perceive accuracy as being the primary goal".
In the real world, there is a difference between accuracy and pedantry.
I (and most reasonable people, that is, those outside of the so-called
"regulars" in this weird ng) claim that the Wiki article about C is
accurate in the parts that matter. That it doesn't measure up to the level
of pedantry required of posters in this group is not particularly relevant.
>> 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.
>
>It's not reasonable to expect them to get stuff right? Okay. That tells us
>all we need to know about Wikipedia, I guess.
In the real world, there is a difference between accuracy and pedantry.
This newsgroup is a nice little haven for people who can't tell the
difference.
Richard Heathfield
> In the real world, there is a difference between accuracy and pedantry.
"Pedantry" is just a word used by people who don't care about accuracy to
describe the attitude of those people who do.
> I (and most reasonable people, that is, those outside of the so-called
> "regulars" in this weird ng) claim that the Wiki article about C is
> accurate in the parts that matter.
The claim, however, is incorrect.
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Kenny McCormack said:
>
>> In the real world, there is a difference between accuracy and pedantry.
>
>"Pedantry" is just a word used by people who don't care about accuracy to
>describe the attitude of those people who do.
Thereby clearly demonstrating that you are in that group of people who
can't tell the difference. Which means this ng is a nice safe padded area
for you.
>> I (and most reasonable people, that is, those outside of the so-called
>> "regulars" in this weird ng) claim that the Wiki article about C is
>> accurate in the parts that matter.
>
>The claim, however, is incorrect.
I guess we just disagree on (the definition of) that which matters.
P.S. I really don't think the typical Wiki reader gives two hoots about
why you shouldn't cast the return value of malloc(). In this context, that
bit of trivia is just BS.
Richard Bos
Meaning, of course, that Wiki is as untrustworthy as your posts, and Mr.
Heathfield was right all along.
Richard
Walter Roberson
Kenny McCormack <gaz...@interaccess.com> wrote:
>I was using BASIC long before there were such things as microcomputers
>(aka, PCs). *Real* BASIC on *real* computers (w/o PEEK/POKE/etc) was/is
>a baby-proof environment.
October 1 1964, Dartmouth, "BASIC", page 1, section I "WHAT IS A PROGRAM?"
A program is a set of directions, a recipie, that is used to provide
an answer to some problem. It usually consists of a set of instructions
to be performed or carried out in a certain order. It starts with the
given data and parameters as the ingredients, and ends up with a
set of answers as the cake. And, as with ordinary cakes, if you make
a mistake in your program, you will end up with something else --
perhaps hash!
http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf
Doesn't sound "user-proof" or "baby-proof" to me. Doesn't sound
substantially different than "nasal demons".
Notice that the manual does not define what happens if one uses
an invalid subscript, or attempts to do a MAT operation between
incompatable matrices. Appendix A does list "SUBSCRIPT ERROR",
but catching subscript problems is not given as part of the
language definition.
>And even you can see that if you invoke machine language from within BASIC,
>well, then you're not programming in BASIC anymore.
But a BASIC that permits such things is not "user-proof".
--
Prototypes are supertypes of their clones. -- maplesoft
Malcolm
> A program is a set of directions, a recipie, that is used to provide
> an answer to some problem. It usually consists of a set of instructions
> to be performed or carried out in a certain order. It starts with the
> given data and parameters as the ingredients, and ends up with a
> set of answers as the cake. And, as with ordinary cakes, if you make
> a mistake in your program, you will end up with something else --
> perhaps hash!
>
dangerous or foolish instructions (such as give the least-well performing
employee the biggest bonus).
Humans usually can do this.
Keith Thompson
[...]
> P.S. I really don't think the typical Wiki reader gives two hoots about
> why you shouldn't cast the return value of malloc(). In this context, that
> bit of trivia is just BS.
I usually try to ignore this troll, but I'm going to make an exception
in this case he's spewing dangerous misinformation, at least by
implication.
It may be true that the typical Wiki reader doesn't care why you
shouldn't cast the return value of malloc(). If it is true, it's only
because the typical Wiki reader is ignorant. Wikipedia itself is
one way to cure that ignorance.
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.
Consider this program:
#include <stdio.h>
#ifdef CORRECT
#include <stdlib.h>
#endif
int main(void)
{
int *ptr = (int*)malloc(sizeof *ptr);
printf("ptr = %p\n", (void*)ptr);
*ptr = 42;
printf("*ptr = %d\n", *ptr);
return 0;
}
When I compile this program on a certain system with "-DCORRECT"
(which has the effect of inserting "#define CORRECT 1" to the top of
the program), the output is:
ptr = 0x6000000000000bc0
*ptr = 42
When I compile the same program without "-DCORRECT", the output is:
ptr = 0xbc0
Segmentation fault
The cast masks a serious error. The compiler warns about "cast to
pointer from integer of different size", but that warning is not
required, and another compiler might compile the dangerously incorrect
code without complaint.
If Kenny thinks that this is an example of the difference between
accuracy and pedantry, he's a fool. But we knew that already.
A note to the regulars of this newsgroup. We know that Kenny is a
troll; he's repeatedly admitted it himself. If you use a killfile,
please add him to it. If you don't, please resist the temptation to
respond to him unless he posts some misinformation that needs to be
corrected. If he doesn't get any attention, perhaps some day he'll go
away and this newsgroup will become a much more pleasant place.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Malcolm
> In the real world, there is a difference between accuracy and pedantry.
> I (and most reasonable people, that is, those outside of the so-called
> "regulars" in this weird ng) claim that the Wiki article about C is
> accurate in the parts that matter. That it doesn't measure up to the
> level
> of pedantry required of posters in this group is not particularly
> relevant.
>
>
> This newsgroup is a nice little haven for people who can't tell the
> difference.
>
difference.
I can talk about "the ASCII representation of the number is stored in the
file", and we all know what I mean. But the computer does need to know
whether I mean the ASCII representation or the machine character
representation.
Richard Heathfield
> Mr. Heathfield was right all along.
There's no need to sound quite so surprised. :-)
use...@zevv.nl
> Richard Bos said:
>
>> Mr. Heathfield was right all along.
>
> There's no need to sound quite so surprised. :-)
Wow, that's *selective* quoting :)
--
:wq
^X^Cy^K^X^C^C^C^C
Nils Weller
Hmm, my own compiler says this about your program:
nils/nwcc_ng [0]> ./nwcc junk.c
junk.c:8: Warning: Incorrect call to `malloc' without declaration,
please `#include <stdlib.h>'
int *ptr = (int*)malloc(sizeof *ptr);
^^^^^^ here
/var/tmp/cpp63.cpp - 0 error(s), 1 warning(s)
:-)
(I've been thinking about doing a complete standard library function
catalogue for diagnosing incorrect library calls in the absence of a
prototype or declaration for some time but haven't gotten around to
doing it yet.)
--
Nils R. Weller, Bremen (Germany)
My real email address is ``nils<at>gnulinux<dot>nl''
... but I'm not speaking for the Software Libre Foundation!
pemo
"Nils Weller" <m...@privacy.net> wrote in message
news:41j14lF...@individual.net...
I love compilers that say 'please' - what are you using?
Keith Thompson
> "Kenny McCormack" <gaz...@yin.interaccess.com> wrote
>> [some stuff]
> [some more stuff]
Please stop feeding the troll. Thank you.
Nils Weller
>
> "Nils Weller" <m...@privacy.net> wrote in message
> news:41j14lF...@individual.net...
>>
>> nils/nwcc_ng [0]> ./nwcc junk.c
>> junk.c:8: Warning: Incorrect call to `malloc' without declaration,
>> please `#include <stdlib.h>'
>> int *ptr = (int*)malloc(sizeof *ptr);
>> ^^^^^^ here
>> /var/tmp/cpp63.cpp - 0 error(s), 1 warning(s)
>>
>> :-)
>
> I love compilers that say 'please' - what are you using?
nwcc! http://sourceforge.net/projects/nwcc/ !
But it's sort of incomplete and broken in a lot of ways so I do not
really use it yet.
Steve Summit
> I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
> written by someone who doesn't know C well enough to use it properly.
>
> The Wikipedia attitude to C is like that of an amateur cook railing against
> the dangers of carving knives, and recommending butter knives for all your
> carving needs.
>
> From a comp.lang.c perspective, then, Wikipedia sucks.
I'm working on it.
Richard Heathfield
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.
Kenny McCormack
Oh great. Just what we need - another outpost of CLC pedantry.
Steve Summit
> Now that basic support for moderation exists, feedback, particularly from
> regulars, and in particular from Steve Summit as FAQ maintainer and
> copyright holder, is solicited:
> * do you support the proposed charter and model of a limited editorial
> group?
> * do you support the proposed content guidelines?
> * is it acceptable/desirable to host the comp.lang.c FAQ on such a wiki?
> * any other issues/concerns.
My first comment is that the question of openness versus control
is an extremely important one. Much virtual ink has been spilled
of late about the alleged unreliability of Wikipedia; that debate
seems to have spilled over even into the sacred, narrow-topic
realm of clc. Clearly it's appallingly irresponsible for
Wikipedia to be openly edited by anyone, even unregistered
anonymous users -- but let's think about that for a moment.
It's also clearly the case that Wikipedia has been as successful
as it has been *because* it can be openly edited by anyone.
It's eminently debatable whether unregistered anonymous users
should have equally free reign, but it's undisputable that
Wikipedia would never have achieved its current momentum if it
had been equipped all along with a proper editorial review board
and article approval process. Wikipedia is as successful as it
is -- and as accurate as it is -- not merely in spite of its open
policies, but because of them.
As I once had occasion to write, "People continue to wish that C
were something it is not, not realizing that if C were what they
thought they wanted it to be, it would never have succeeded and
they wouldn't be using it in the first place." And I think wikis
are much the same.
A C Wiki, with its smaller scope and more constrained subject
matter, could probably get away with a little more control (aka
closedness) than the every-topic-is-fair-game Wikipedia, but I
suspect it will still be important that it be relatively open,
where by "relatively" I mean "more than would seem prudent".
If it is open, yes, it may suffer from some of the same kinds
of transient inaccuracy that Wikipedia is notorious for. But if
it is closely controlled, and no matter how well-intentioned that
control is to prevent vandalism and ill-informed speculation,
the project will be at significant risk of never getting off the
ground at all.
I would urge the proponents of the C Wiki to, as Wikipedia puts
it, *be* *bold* and just do it. I didn't ask for anyone's
permission or support when I started compiling the FAQ list lo
those many years ago, and no one needs permission to start a C
Wiki, either. And, more to the point: don't worry too much about
getting the model and the charter and the editorial board and the
voting policy all perfect before you start. There's another
analogy to trot out here, equally if not more applicable in the
context of C, namely: Richard P. Gabriel's old dichotomy between
"MIT" and "New Jersey", the infamous "Worse is Better" philosophy.
If you have a good idea, set it free and let it run. If it's a
truly good idea, it will thrive under this freedom and become
better than you ever imagined. If it founders, perhaps it wasn't
such a good idea anyway, and in any case, it probably wouldn't
have fared any better under too-tight control, either.
On the specific question of "seeding" a C Wiki with the
comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
do hold the copyright and can do almost anything I want with the
content, but on the other hand Addison Wesley also has a vested
interest and a particular copyright notice they'd like to retain,
so it probably won't be possible to just release the whole FAQ
list under the GFDL. But I'd like to see if we can do something,
because while on the one hand I am (I confess) still possessive
enough about the thing that I'll have some qualms about throwing
it open for anyone to edit, on the other hand I've been wondering
how I'm ever going to cede control over it, since I don't
maintain it as actively as I once did and I'm certainly not going
to maintain it forever. I've been wondering if it's time to fork
it, and doing so in the context of a C Wiki might be just the
thing.
At the very least we could certainly seed the FAQ List section
of a C Wiki with the questions from the existing FAQ list,
bidirectionally cross-referenced with the "static" answers
I maintain, with the more dynamic, Wiki-side answer sections
serving to amplify or annotate or extend or eventually supplant
the static ones. But that would be kind of an awkward split, and
I can probably see my way clear to having the Wiki-side answers
seeded with the existing static answer text also, as long as it's
possible to tag those pages with a different, non-GFDL copyright
notice. I'll keep thinking about this, and maybe raise the
question with the editors I've been talking with at Addison
Wesley lately.
A couple of other notes:
I'm glad to see the Wikimedia software being used, rather than
something being written from scratch!
They're hinted at in the existing topic outline, but it would be
lovely to have a collaboratively written, Wiki-mediated language
tutorial, a language reference manual, and a library reference
manual in there, too.
At any rate, let's see some more discussion about the Wiki idea!
I think it has a lot of promise, which is why I'm blathering at
length about it in this public post, rather than just sending an
email reply to Netocrat.
Steve Summit
s...@eskimo.com
Flash Gordon
> Netocrat wrote:
>> Now that basic support for moderation exists, feedback, particularly from
>> regulars, and in particular from Steve Summit as FAQ maintainer and
>> copyright holder, is solicited:
>> * do you support the proposed charter and model of a limited editorial
>> group?
>> * do you support the proposed content guidelines?
>> * is it acceptable/desirable to host the comp.lang.c FAQ on such a wiki?
>> * any other issues/concerns.
Steve, first off thank you for your support in this.
> My first comment is that the question of openness versus control
> is an extremely important one. Much virtual ink has been spilled
<snip>
> A C Wiki, with its smaller scope and more constrained subject
> matter, could probably get away with a little more control (aka
> closedness) than the every-topic-is-fair-game Wikipedia, but I
> suspect it will still be important that it be relatively open,
> where by "relatively" I mean "more than would seem prudent".
> If it is open, yes, it may suffer from some of the same kinds
> of transient inaccuracy that Wikipedia is notorious for. But if
> it is closely controlled, and no matter how well-intentioned that
> control is to prevent vandalism and ill-informed speculation,
> the project will be at significant risk of never getting off the
> ground at all.
There is always the option of having things wide open initially and
tightening up control if it becomes a problem. My biggest reservations
are about anonymous editing, but I'm only one voice.
> I would urge the proponents of the C Wiki to, as Wikipedia puts
> it, *be* *bold* and just do it. I didn't ask for anyone's
<snip>
Well, the site is up and running and people are welcome to create
accounts and start editing.
> On the specific question of "seeding" a C Wiki with the
> comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
> do hold the copyright and can do almost anything I want with the
> content, but on the other hand Addison Wesley also has a vested
> interest and a particular copyright notice they'd like to retain,
> so it probably won't be possible to just release the whole FAQ
> list under the GFDL.
I would be happy to add statements like, "The initial content of this
page is copyright Steve Summit with modifications under the GFDL. See
http://c-faq.com/ for the original."
We could also include on the page footer something like, "This site has
been seeded from the C FAQ, copyright Steve Summit, See
http://c-faq.com/ for Steve's work". This could be put in such that it
is impossible for it to be edited.
<snip>
> At the very least we could certainly seed the FAQ List section
> of a C Wiki with the questions from the existing FAQ list,
> bidirectionally cross-referenced with the "static" answers
> I maintain, with the more dynamic, Wiki-side answer sections
> serving to amplify or annotate or extend or eventually supplant
> the static ones. But that would be kind of an awkward split, and
> I can probably see my way clear to having the Wiki-side answers
> seeded with the existing static answer text also, as long as it's
> possible to tag those pages with a different, non-GFDL copyright
> notice. I'll keep thinking about this, and maybe raise the
> question with the editors I've been talking with at Addison
> Wesley lately.
Indeed. I'm sure something mutually acceptable can be arranged.
One other thing we could do, if you are willing, if have you point
sometime like wiki.c-faq.com at the site. I would have to do a small
edit to my Apache configuration to support it, but it would put the
domain in to hands rather better known than mine.
> A couple of other notes:
>
> I'm glad to see the Wikimedia software being used, rather than
> something being written from scratch!
We are SW developers, so we are lazy by nature ;-)
> They're hinted at in the existing topic outline, but it would be
> lovely to have a collaboratively written, Wiki-mediated language
> tutorial, a language reference manual, and a library reference
> manual in there, too.
Yes, those are all good ideas.
> At any rate, let's see some more discussion about the Wiki idea!
> I think it has a lot of promise, which is why I'm blathering at
> length about it in this public post, rather than just sending an
> email reply to Netocrat.
Thanks again for your support.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Giannis Papadopoulos
> Netocrat wrote:
>
>>Now that basic support for moderation exists, feedback, particularly from
>>regulars, and in particular from Steve Summit as FAQ maintainer and
>>copyright holder, is solicited:
>>* do you support the proposed charter and model of a limited editorial
>> group?
>>* do you support the proposed content guidelines?
>>* is it acceptable/desirable to host the comp.lang.c FAQ on such a wiki?
>>* any other issues/concerns.
In my turn, I also thank you for having such a positive stance for a
wannabe c.l.c wiki.
> My first comment is that the question of openness versus control
> is an extremely important one. Much virtual ink has been spilled
> of late about the alleged unreliability of Wikipedia; that debate
> seems to have spilled over even into the sacred, narrow-topic
> realm of clc. Clearly it's appallingly irresponsible for
> Wikipedia to be openly edited by anyone, even unregistered
> anonymous users -- but let's think about that for a moment.
>
> It's also clearly the case that Wikipedia has been as successful
> as it has been *because* it can be openly edited by anyone.
> It's eminently debatable whether unregistered anonymous users
> should have equally free reign, but it's undisputable that
> Wikipedia would never have achieved its current momentum if it
> had been equipped all along with a proper editorial review board
> and article approval process. Wikipedia is as successful as it
> is -- and as accurate as it is -- not merely in spite of its open
> policies, but because of them.
Although openness would be a major benefit, we ought to think about
people that think they know C, and might try to contribute, whereas they
are propagating errors and misunderstandings.
In Wikipedia it works, because it has many editors, maybe more than a
language-specific wiki (such as the proposed one) will ever have. So a
more restrictive stance seems to be the way to go, at least for the time
being. However, no rule is meant to last for ever.
Moreover, your C FAQ has reached another level of perfection - after so
many years of dedication, corrections and additions - and it would be
very precarious to leave it open for everyone.
> A C Wiki, with its smaller scope and more constrained subject
> matter, could probably get away with a little more control (aka
> closedness) than the every-topic-is-fair-game Wikipedia, but I
> suspect it will still be important that it be relatively open,
> where by "relatively" I mean "more than would seem prudent".
> If it is open, yes, it may suffer from some of the same kinds
> of transient inaccuracy that Wikipedia is notorious for. But if
> it is closely controlled, and no matter how well-intentioned that
> control is to prevent vandalism and ill-informed speculation,
> the project will be at significant risk of never getting off the
> ground at all.
However, if it manages to get off the ground IMHO it would be a major
contribution.. And I think it worths the risk.
> On the specific question of "seeding" a C Wiki with the
> comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
> do hold the copyright and can do almost anything I want with the
> content, but on the other hand Addison Wesley also has a vested
> interest and a particular copyright notice they'd like to retain,
> so it probably won't be possible to just release the whole FAQ
> list under the GFDL. But I'd like to see if we can do something,
> because while on the one hand I am (I confess) still possessive
> enough about the thing that I'll have some qualms about throwing
> it open for anyone to edit, on the other hand I've been wondering
> how I'm ever going to cede control over it, since I don't
> maintain it as actively as I once did and I'm certainly not going
> to maintain it forever. I've been wondering if it's time to fork
> it, and doing so in the context of a C Wiki might be just the
> thing.
We can search some other ways to have GNU FDL and copyrighted material
in the same place. I don't think that this is out of the question. It
could, for example, have the copyrighted C FAQ question and answer, and
after that the FDL part that either complements the answer or gives
other directions, hints etc.
> At the very least we could certainly seed the FAQ List section
> of a C Wiki with the questions from the existing FAQ list,
> bidirectionally cross-referenced with the "static" answers
> I maintain, with the more dynamic, Wiki-side answer sections
> serving to amplify or annotate or extend or eventually supplant
> the static ones. But that would be kind of an awkward split, and
> I can probably see my way clear to having the Wiki-side answers
> seeded with the existing static answer text also, as long as it's
> possible to tag those pages with a different, non-GFDL copyright
> notice. I'll keep thinking about this, and maybe raise the
> question with the editors I've been talking with at Addison
> Wesley lately.
FDL is extremely versatile. I am not a lawyer or a patent-guy, but I
think that after some careful discussion, there might be a way.
> A couple of other notes:
>
> I'm glad to see the Wikimedia software being used, rather than
> something being written from scratch!
It is tested and it works and it is now the heart of the c.l.c wiki
thanks to Netocrat and Flash Gordon.
> They're hinted at in the existing topic outline, but it would be
> lovely to have a collaboratively written, Wiki-mediated language
> tutorial, a language reference manual, and a library reference
> manual in there, too.
Yes, that would be nice.. However, the main focus is the FAQ (the first
step is the start for even the longest journey - isn't that a chinese
saying?) just because currently there aren't many people involved...
Al Balmer
<sp...@flash-gordon.me.uk> wrote:
>> A C Wiki, with its smaller scope and more constrained subject
>> matter, could probably get away with a little more control (aka
>> closedness) than the every-topic-is-fair-game Wikipedia, but I
>> suspect it will still be important that it be relatively open,
>> where by "relatively" I mean "more than would seem prudent".
>> If it is open, yes, it may suffer from some of the same kinds
>> of transient inaccuracy that Wikipedia is notorious for. But if
>> it is closely controlled, and no matter how well-intentioned that
>> control is to prevent vandalism and ill-informed speculation,
>> the project will be at significant risk of never getting off the
>> ground at all.
>
>There is always the option of having things wide open initially and
>tightening up control if it becomes a problem. My biggest reservations
>are about anonymous editing, but I'm only one voice.
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.
(Sorry I don't have a reference to the new encyclopedia.)
--
Al Balmer
Sun City, AZ
Jordan Abel
> Jordan Abel said:
>
>>> And if you browse around the Wiki for a while, you'll find other articles
>>> on C, each of which has their own little collection of mistakes.
>>
>> Such as? (Yes, he's a troll, but you haven't given any specific examples
>> of facts claimed that are false, and the article really doesn't look to
>> me as bad as you claim it is)
>
> I've already pointed out several faults with the lead article.
>
> Observe the first program example on this page:
>
> <http://en.wikipedia.org/wiki/C_syntax>
>
>
> void setInt(int **p, int n)
> {
> *p = (int *) malloc(sizeof(int)); // allocate a memory area, using
> the pointer given as as a parameter [1]
>
> **p = n;
> }
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
>
> int main(void)
> {
> int *p; // create a pointer to an integer
> setInt(&p, 42); // pass the address of 'p'
> return 0;
> }
>
> [1] Originally presented as a single line.
>
> If this is C90 code, count the bugs.
> If it's C99 code instead, count the bugs.
Other than the comments, i don't see any c90 bugs. i don't see any c99
bugs at all. and there certainly are no syntax errors. It's a bit of a
contrived example, but the only real problem with it is the cast [and
the lack of inclusion of stdlib, but it's arguably a mere code snippet,
rather than a complete source file
the more serious problem is that it says "<data-type> varN" - which
implies that it's int[42] a instead of int a[42] to declare an array of
42 ints.
>
> Not even my cat would use scanf like that. (The kitten might.)
>
> These are not the only problems, by any means. Now, if you want to find any
> more, go look for yourself.