473,320 Members | 1,870 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

gets() - dangerous?

Lee
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
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

Dec 24 '05
302 18206
Kenny McCormack said:
In article <do**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 27 '05 #51
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.

--
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)
Dec 27 '05 #52
Lee wrote:
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.


http://www.insecure.org/stf/smashstack.txt
Dec 27 '05 #53

"Richard Heathfield" <in*****@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.

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.
Dec 27 '05 #54
Malcolm said:
"Richard Heathfield" <in*****@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.

--
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)
Dec 28 '05 #55

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

Dec 28 '05 #56
James Dow Allen said:
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.

--
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)
Dec 28 '05 #57
James Dow Allen wrote:
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


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.

Dec 28 '05 #58
James Dow Allen wrote:

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
as big as necessary. [...]


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
es*****@acm-dot-org.invalid
Dec 28 '05 #59
Eric Sosman said:
James Dow Allen wrote:

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
as big as necessary. [...]


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?


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

--
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)
Dec 28 '05 #60
In article <xq********************@comcast.com>,
Eric Sosman <es*****@acm-dot-org.invalid> wrote:
James Dow Allen wrote:

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
as big as necessary. [...]


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?


For the same reason most people use safety belts in cars.

Dec 28 '05 #61
Richard Heathfield wrote:
Joe Wright said:
When was it that use of gets() became widely known as evil?


1988, I think.

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
Dec 28 '05 #62

"Richard Heathfield" <in*****@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.

I've now read the article.

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.
Dec 28 '05 #63
In article <do**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Malcolm <re*******@btinternet.com> wrote:

"Richard Heathfield" <in*****@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.

I've now read the article.

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.


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.

Dec 28 '05 #64
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.

--
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)
Dec 28 '05 #65
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.

Dec 28 '05 #66
Kenny McCormack said:
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.

--
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)
Dec 28 '05 #67
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Kenny McCormack said:
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.

Dec 29 '05 #68
On 2005-12-28, Richard Heathfield <in*****@invalid.invalid> wrote:
Kenny McCormack said:
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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)
Dec 29 '05 #69
ga*****@yin.interaccess.com (Kenny McCormack) wrote:
In article <do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.


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
Dec 29 '05 #70
In article <do**********@yin.interaccess.com>,
Kenny McCormack <ga*****@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
Dec 29 '05 #71
Kenny McCormack said:
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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dec 29 '05 #72
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>

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.

--
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)
Dec 29 '05 #73
we******@gmail.com wrote:
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.

--
http://members.dodo.com.au/~netocrat
Dec 29 '05 #74
In article <dp**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@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.

Dec 29 '05 #75
In article <43***************@news.xs4all.nl>,
Richard Bos <rl*@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.

Dec 29 '05 #76
In article <dp**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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)

Dec 29 '05 #77
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".
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.

--
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)
Dec 29 '05 #78
In article <dp**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.

Dec 29 '05 #79
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.
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.
--
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)
Dec 29 '05 #80
In article <dp**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@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.

Dec 29 '05 #81
ga*****@yin.interaccess.com (Kenny McCormack) wrote:
In article <43***************@news.xs4all.nl>,
Richard Bos <rl*@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."


Meaning, of course, that Wiki is as untrustworthy as your posts, and Mr.
Heathfield was right all along.

Richard
Dec 29 '05 #82
In article <dp**********@yin.interaccess.com>,
Kenny McCormack <ga*****@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
Dec 29 '05 #83
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote
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!

No computer programming language can second-guess the programmer and ignore
dangerous or foolish instructions (such as give the least-well performing
employee the biggest bonus).
Humans usually can do this.
Dec 29 '05 #84
ga*****@yin.interaccess.com (Kenny McCormack) writes:
[...]
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.
Dec 29 '05 #85
"Kenny McCormack" <ga*****@yin.interaccess.com> wrote
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.

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.

The problem is that computer's aren't intelligent enough to know the
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.
Dec 29 '05 #86
Richard Bos said:
Mr. Heathfield was right all along.


There's no need to sound quite so surprised. :-)

--
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)
Dec 29 '05 #87
Richard Heathfield <in*****@invalid.invalid> wrote:
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
Dec 29 '05 #88
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
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.


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!
Dec 29 '05 #89

"Nils Weller" <me@privacy.net> wrote in message
news:41*************@individual.net...
On 2005-12-29, Keith Thompson <ks***@mib.org> wrote:
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.


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!


I love compilers that say 'please' - what are you using?
Dec 29 '05 #90
"Malcolm" <re*******@btinternet.com> writes:
"Kenny McCormack" <ga*****@yin.interaccess.com> wrote
[some stuff]

[some more stuff]


Please stop feeding the troll. Thank you.

--
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.
Dec 29 '05 #91
On 2005-12-29, pemo <us***********@gmail.com> wrote:

"Nils Weller" <me@privacy.net> wrote in message
news:41*************@individual.net...
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 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.

--
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!
Dec 29 '05 #92
Richard Heathfield wrote:
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.
Dec 30 '05 #93
Steve Summit said:
Richard Heathfield wrote:
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.


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.

--
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)
Dec 30 '05 #94
In article <dp**********@eskinews.eskimo.com>,
Steve Summit <sc*@eskimo.com> wrote:
Richard Heathfield wrote:
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.


Oh great. Just what we need - another outpost of CLC pedantry.

Dec 30 '05 #95
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.


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
sc*@eskimo.com
Dec 30 '05 #96
Steve Summit wrote:
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.
Dec 30 '05 #97
Steve Summit wrote:
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...
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
sc*@eskimo.com

Dec 30 '05 #98
On Fri, 30 Dec 2005 13:00:07 +0000, Flash Gordon
<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
Dec 30 '05 #99
On 2005-12-29, Richard Heathfield <in*****@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>

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;
}


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.

Dec 30 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

32
by: Marcus | last post by:
We all know that the "gets" function from the Standard C Library (which is part of the Standard C++ Library) is dangerous. It provides no bounds check, so it's easy to overwrite memory when using...
57
by: Eric Boutin | last post by:
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or gets function... I mean.. if I do : char a; scanf("%s", a); and the user input a 257 char string.. that creates a...
89
by: Cuthbert | last post by:
After compiling the source code with gcc v.4.1.1, I got a warning message: "/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the 'gets' function is dangerous and should not be...
280
by: jacob navia | last post by:
In the discussion group comp.std.c Mr Gwyn wrote: < quote > .... gets has been declared an obsolescent feature and deprecated, as a direct result of my submitting a DR about it (which...
104
by: jayapal | last post by:
Hi all, Whenever I use the gets() function, the gnu c compiler gives a warning that it is dangerous to use gets(). why...? regards, jayapal.
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.