473,417 Members | 1,540 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,417 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 18253
we******@gmail.com wrote:
Chuck F. wrote:

... snip ...

You have re-invented strlcpy, without some of the provisions
specified for its action. For details of this see:

<http://cbfalconer.home.att.net/download/strlcpy.zip>

At any rate, here is the heart code of my implementation. Notice
that it doesn't use the library at all, and thus is suitable for
embedded applications. Since it has to scan the length of the
source string it combines that with the actual transfer, for
noticeable efficiency improvement.

size_t strlcpy(char *dst, const char *src, size_t sz)
{
const char *start = src;

if (src && sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
if (src) {
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */


I am confused by this implementation of successive src tests.
Are you expecting it to be possible to set src = (char *)
((NULL) - (int)k) or something? The chances that that means
something on a platform seems pretty low. Why wouldn't you just
hoist out the "if (src)" test? (Attention Edward G. Niles: use
my second sentence to determine *WHY* the C compiler cannot do
the hoist automatically.)


Why are you proposing such undefined behavior operations? No sane
programmer would ever pass such a parameter.

Among other things it caters to passing NULL as the src parameter,
and treats it as an empty string. Download the source for some
implications and requirements. The code has been minimized in
anticipation of embedded system use with non-optimizing compilers.

--
"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/>
Jan 9 '06 #201
Chuck F. wrote:
we******@gmail.com wrote:
Chuck F. wrote:
... snip ...

You have re-invented strlcpy, without some of the provisions
specified for its action. For details of this see:

<http://cbfalconer.home.att.net/download/strlcpy.zip>

At any rate, here is the heart code of my implementation. Notice
that it doesn't use the library at all, and thus is suitable for
embedded applications. Since it has to scan the length of the
source string it combines that with the actual transfer, for
noticeable efficiency improvement.

size_t strlcpy(char *dst, const char *src, size_t sz)
{
const char *start = src;

if (src && sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
if (src) {
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */


I am confused by this implementation of successive src tests.
Are you expecting it to be possible to set src = (char *)
((NULL) - (int)k) or something? The chances that that means
something on a platform seems pretty low. Why wouldn't you just
hoist out the "if (src)" test? (Attention Edward G. Niles: use
my second sentence to determine *WHY* the C compiler cannot do
the hoist automatically.)


Why are you proposing such undefined behavior operations? No sane
programmer would ever pass such a parameter.


Its not me -- its *YOU* by the way you wrote the code. What I am
asking is, why not implement it as:

size_t strlcpy(char *dst, const char *src, size_t sz) {
if (src) {
const char *start = src;
if(sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */

This saves you one if(src) test, and you avoid setting start if its not
necessary. Its called "hoisting". Of course this transformation is
technically incorrect if your platform lets you define src = (char *)
((NULL) - (int)k), where k = min(sz,strlen(src)) for some reason
because the two if(src) tests that you do will go in opposite
directions. In other words you would still prefer your implementation
to mine if you need to support that bizarre corner case in what is
otherwise undefined behavior.

Whatever dude, it was just a question. I assumed that as an expert on
"strlcpy" you could elucidate on what I was missing; but as I look at
it again, it seems clear that I am not missing anything.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jan 9 '06 #202
Markus Becker <ye*******@web.de> wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> schrieb:
This is not tedious and does not involve strlen(); it is called planning
ahead, a skill all programmers should have but astonishingly few do.


Some programming activity (in the real world) have to deal with
code already existing and 'proven to work, not to be touched,
but to be used..'.


Yes, and? Sure, strcpy() can be abused. So can printf().

Richard
Jan 9 '06 #203
In article <43****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
Markus Becker <ye*******@web.de> wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> schrieb:
> This is not tedious and does not involve strlen(); it is called planning
> ahead, a skill all programmers should have but astonishingly few do.


Some programming activity (in the real world) have to deal with
code already existing and 'proven to work, not to be touched,
but to be used..'.


Yes, and? Sure, strcpy() can be abused. So can printf().

Richard


You are the master of the non-sequitor, aren't you?
I bow to your mastery of the technique.

Jan 9 '06 #204
Kenny McCormack wrote:
You are the master of the non-sequitor, aren't you?


ITYM non-sequitur

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jan 9 '06 #205
we******@gmail.com wrote:
Chuck F. wrote:
we******@gmail.com wrote:
> Chuck F. wrote:
>> ... snip ...
>>
>> You have re-invented strlcpy, without some of the provisions
>> specified for its action. For details of this see:
>>
>> <http://cbfalconer.home.att.net/download/strlcpy.zip>
>>
>> At any rate, here is the heart code of my implementation. Notice
>> that it doesn't use the library at all, and thus is suitable for
>> embedded applications. Since it has to scan the length of the
>> source string it combines that with the actual transfer, for
>> noticeable efficiency improvement.
>>
>> size_t strlcpy(char *dst, const char *src, size_t sz)
>> {
>> const char *start = src;
>>
>> if (src && sz--) {
>> while ((*dst++ = *src))
>> if (sz--) src++;
>> else {
>> *(--dst) = '\0';
>> break;
>> }
>> }
>> if (src) {
>> while (*src++) continue;
>> return src - start - 1;
>> }
>> else if (sz) *dst = '\0';
>> return 0;
>> } /* strlcpy */
>
> I am confused by this implementation of successive src tests.
> Are you expecting it to be possible to set src = (char *)
> ((NULL) - (int)k) or something? The chances that that means
> something on a platform seems pretty low. Why wouldn't you just
> hoist out the "if (src)" test? (Attention Edward G. Niles: use
> my second sentence to determine *WHY* the C compiler cannot do
> the hoist automatically.)


Why are you proposing such undefined behavior operations? No sane
programmer would ever pass such a parameter.


Its not me -- its *YOU* by the way you wrote the code. What I am
asking is, why not implement it as:

size_t strlcpy(char *dst, const char *src, size_t sz) {
if (src) {
const char *start = src;
if(sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */


Now that you show the proposed code, I can agree, I think. I would
still have to test the various extreme conditions to be sure. I
looked no further than the ridiculous input parameter suggestion.

At any rate I never worried about a few tests outside the mail
loops. They will happen once per call. I did worry about complex
tests within the loops.

--
"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/>
Jan 9 '06 #206
Daniel Rudy wrote:
At about the time of 1/3/2006 5:59 AM, Christian Bau stated the following:
"Targeur fou" <rt******@yahoo.fr> wrote:
The more dangerous problem with strncpy is: If the destination buffer is
not large enough, what it copies _is not a valid C string_!!! It doesn't
append a trailing zero! If you use strncpy to copy into a 10 byte
buffer, and the source string is too long, it copies 10 bytes instead of
copying 9 bytes and a trailing zero, which at least would have given you
a valid C string.

I guess it is time to write your own function that does what it should
do: strcpy if the result fits, copy a valid C string by dropping
trailing characters if the result doesn't fit. You still have to be
careful, but at least you won't get a buffer overflow and undefined
behavior.


There already is a function that does that: strlcpy and strlcat. The
performance is much higher for strlcpy than for strncpy.


Lol! Its *faster* you say? Don't both of them boil down to:

do {
if ('\0' == (*dst++ = *src;)) break; /* Toddler: "Are we there
yet?" */
src++;
} while (--count); /* Parent: Watching the road signs */

in their inner loops? (There are tricks you can pull to alias the
count and src decrement/increment that useful in x86 ASM, but it likely
won't make a difference in today's modern OOE architectures.)

I thought strlcpy was just marginally safer than strncpy (because of
its more predictable truncation and termination semantics.) If you
want speed you can't beat memcpy() (and neither can I, because I don't
know the assembly language of every architecture where a C compiler has
been made) and that really *DOES* outperform strcpy, strlcpy and
strncpy (think of it as giving the Toddler a tranquelizer).

The number of iterations through the loop in memcpy does not depend on
the raw string data (i.e., searching for '\0's), but rather an
asynchronous count (which is just sitting in a register somewhere) --
this is a lot better for modern CPUs which prefer parallelism to
dependency after dependency.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jan 10 '06 #207
we******@gmail.com wrote:
.... snip ...
I thought strlcpy was just marginally safer than strncpy
(because of its more predictable truncation and termination
semantics.) If you want speed you can't beat memcpy() (and
neither can I, because I don't know the assembly language of
every architecture where a C compiler has been made) and that
really *DOES* outperform strcpy, strlcpy and strncpy (think of
it as giving the Toddler a tranquelizer).


The time problem with strncpy is that it always pads the whole
buffer with '\0', and if the buffer has been filled it won't
bother. strlcpy doesn't go any further than it needs to, and
always terminates the string properly. It also returns the size of
the resultant string, so you don't need to spend time executing strlen.

Look a little deeper than the one routine.

--
"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/>
Jan 10 '06 #208
This reply was delayed as I wanted to complete some development on the
wiki and set up a generic domain name before responding to Steve's post.
The wiki's now accessible through clc-wiki.net.

On Fri, 30 Dec 2005 10:19:19 +0000, Steve Summit wrote:
My first comment is that the question of openness versus control is an
extremely important one. [i]t'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. [...] 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. ...
That's probably true, and we can leave editing unrestricted except for
anonymous edits unless problems occur. Email notification now supports
global creation/change watches, although the patch hasn't been applied
live yet, and we'll probably add category and namespace watches too.
I would urge the proponents of the C Wiki to, as Wikipedia puts it, *be*
*bold* and just do it. [D]on't worry too much about getting the model
and the charter and the editorial board and the voting policy all
perfect before you start.
The suggestion to incorporate something as official (as it has become) as
the c.l.c FAQ seemed to require a more perfectionist approach, but in the
FAQ's absence a good-enough approach should work fine. New features can
be added as needed.

Content's more relevant and some starting content has been imported - the
K&R2 solutions from RJH's unmaintained site:
<http://clc-wiki.net/wiki/KR2_Chapter_Index>
or through the original domain name:
<http://clc.flash-gordon.me.uk/wiki/KR2_Chapter_Index>.

[...] On the specific question of "seeding" a C Wiki with the comp.lang.c FAQ
list, I'm still of mixed mind. ... [W]hile 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.
The wiki model could support a page owner (a review group of one), and the
stable version of the article would need to be approved by the page owner.
The "unmoderated" edit version would still be viewable, but wouldn't be
shown by default. That's one possibility - for the FAQ you would be the
pages' owner and stable version setter.
At the very least we could certainly seed the FAQ List section of a C
Wiki with the questions from the existing FAQ list ... 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. ...
There's probably not a lot of value in starting a separate version of the
FAQ from scratch bar the question wordings, especially when the current
content of the FAQ is so well-regarded by the c.l.c community. If you
decide not to wikify the FAQ answers, then I think a c.l.c wiki should
avoid the role of a FAQ and focus on other content - your suggestions
below are good ones.
A couple of other notes:

I'm glad to see the Wikimedia software being used, rather than something
being written from scratch!
It's pretty feature-rich and where we add features we'll contribute them
back to the MediaWiki developers.
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.
Another possibility is portable, peer-reviewed standard library function
implementations - I've noticed a few regulars mentioning personal learning
projects around that theme - anyone interested in contributing/reviewing
code?

Contributions of summaries of useful threads with discussion, code,
improvement processes or realistic portable optimisation examples would
also be welcome, as would personal style guidelines with rationale.
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 your support is much appreciated.

--
http://members.dodo.com.au/~netocrat
Jan 14 '06 #209
Netocrat said:
Content's more relevant and some starting content has been imported - the
K&R2 solutions from RJH's unmaintained site:
<http://clc-wiki.net/wiki/KR2_Chapter_Index>


I took a quick look, and I think you've made a good job of this. (It was a
/very/ quick look, but what I saw didn't make me think "oh deary deary me",
so I guess that's a good sign.)

I had been contemplating hoiking the whole thing over to my current site,
but now I will gratefully not bother.

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

I hope I'm right in thinking that you won't allow idiots to undo experts'
changes.

(Steve Summit said)
At any rate, let's see some more discussion about the Wiki idea!


Agreed. I think this newsgroup is the right place to discuss it, too, if we
wish to avoid the problems Wikipedia faces with quality. And it'll make a
pleasant change from wittering on about void main.

I don't know whether clc-wiki.net aims to restrict itself purely to portable
C. If it doesn't, it will need to institute an apartheid principle to make
it abundantly clear what is portable and what is not, and discussion of the
non-portable bits should be done elsenet.

--
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)
Jan 14 '06 #210
On Sat, 14 Jan 2006 06:58:42 +0000, Richard Heathfield wrote:
Netocrat said:
Content's more relevant and some starting content has been imported -
the K&R2 solutions from RJH's unmaintained site:
<http://clc-wiki.net/wiki/KR2_Chapter_Index>
I took a quick look, and I think you've made a good job of this. (It was
a /very/ quick look, but what I saw didn't make me think "oh deary deary
me", so I guess that's a good sign.)


That's good to know. The changes from html to wiki markup were minor
anyhow - the wiki engine does a good job of presentation.
I had been contemplating hoiking the whole thing over to my current
site, but now I will gratefully not bother.

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]
Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)
I hope I'm right in thinking that you won't allow idiots to undo
experts' changes.
As it stands there's nothing to prevent anyone from creating an account
and making changes. Given that there's very little traffic on the wiki
it's easy to monitor all changes though (web/RSS) - so any "idiot undos"
can be shortly reverted. I'm monitoring the site and I presume the other
wiki planners are too; more and expert monitors would be useful.
(Steve Summit said)
At any rate, let's see some more discussion about the Wiki idea!

Agreed. I think this newsgroup is the right place to discuss it, too, if
we wish to avoid the problems Wikipedia faces with quality. And it'll
make a pleasant change from wittering on about void main. I don't know
whether clc-wiki.net aims to restrict itself purely to portable C.


The wiki's topicality follows from comp.lang.c's - the main difference is
that longer articles are possible and it can present tangential
information such as resource lists. This is slightly unrelated, but I've
just added a "Community And Resources" category and two articles in that
category:
* <http://clc-wiki.net/wiki/Home_Pages>
if you have a c-related home-page and you post to comp.lang.c or are a
committee member, feel free to add it to this list; also if you don't
want to be listed there you can remove yourself
* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.
If it doesn't, it will need to institute an apartheid principle to make
it abundantly clear what is portable and what is not, and discussion of
the non-portable bits should be done elsenet.


Any non-portable code/discussion should be as incidental and clearly
demarcated as it generally is in posts to this newsgroup.

--
http://members.dodo.com.au/~netocrat
Jan 14 '06 #211
Netocrat said:
On Sat, 14 Jan 2006 06:58:42 +0000, Richard Heathfield wrote:
Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]
Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)


Oh, I don't mind sticking my oar in, as long as I don't have to get my hands
dirty. :-)

I hope I'm right in thinking that you won't allow idiots to undo
experts' changes.


As it stands there's nothing to prevent anyone from creating an account
and making changes.


Um, eesh. Why not just take the brewery keys down to the nearest collection
of park benches?
Given that there's very little traffic on the wiki
it's easy to monitor all changes though (web/RSS) - so any "idiot undos"
can be shortly reverted. I'm monitoring the site and I presume the other
wiki planners are too; more and expert monitors would be useful.
If expert monitors have a really easy way to learn what has been changed,
then that sounds like a plan.
(Steve Summit said)
At any rate, let's see some more discussion about the Wiki idea!
Agreed. I think this newsgroup is the right place to discuss it, too, if
we wish to avoid the problems Wikipedia faces with quality. And it'll
make a pleasant change from wittering on about void main. I don't know
whether clc-wiki.net aims to restrict itself purely to portable C.


The wiki's topicality follows from comp.lang.c's - the main difference is
that longer articles are possible and it can present tangential
information such as resource lists. This is slightly unrelated, but I've
just added a "Community And Resources" category and two articles in that
category:
* <http://clc-wiki.net/wiki/Home_Pages>
if you have a c-related home-page and you post to comp.lang.c or are a
committee member, feel free to add it to this list; also if you don't
want to be listed there you can remove yourself


Here's a suggestion for you - pop over to
http://www.cpax.org.uk/prg/portable/c/resources.php and steal the entire
page. (Make sure you read it over, though, since some of it won't survive a
change of ownership and will need editing.)
* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.


I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem to
think he is), his signal-to-noise ratio is way too low.

--
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)
Jan 14 '06 #212
In article <dq**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
....
* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.


I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem to
think he is), his signal-to-noise ratio is way too low.


As anyone can clearly see, its a lot higher than yours. You are
troll-central.

Just out curiosity, what is your definition of "troll"? What would I have
to do or not do to qualify?

Jan 14 '06 #213
Kenny McCormack said:
Just out curiosity, what is your definition of "troll"? What would I have
to do or not do to qualify?


Don't worry about it; you're doing just fine.
--
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)
Jan 14 '06 #214
On Sat, 14 Jan 2006 14:16:57 +0000, Richard Heathfield wrote:
Netocrat said:
On Sat, 14 Jan 2006 06:58:42 +0000, Richard Heathfield wrote:
Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]
Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)


Oh, I don't mind sticking my oar in, as long as I don't have to get my
hands dirty. :-)


Let's keep things clean then - starting with a ban on offensive language.
I hope I'm right in thinking that you won't allow idiots to undo
experts' changes.


As it stands there's nothing to prevent anyone from creating an account
and making changes.


Um, eesh. Why not just take the brewery keys down to the nearest
collection of park benches?


Yes, I understand that you're skeptical of the open approach, and to a
point I am too (one reason the c.l.c wiki interests me is trying to work
out a middle approach). The key difference here is: once the beer's
drunk, it can't be reclaimed; an edit can be reverted and the "theft"
lasts for only as long as it isn't noticed. That's why I think that a
stable version would work well - the theft isn't visible to the casual
reader but it is to anyone monitoring, particularly the review group.
Given that there's very little traffic on the wiki it's easy to monitor
all changes though (web/RSS) - so any "idiot undos" can be shortly
reverted. I'm monitoring the site and I presume the other wiki
planners are too; more and expert monitors would be useful.


If expert monitors have a really easy way to learn what has been
changed, then that sounds like a plan.


Let us know if you find a deficiency in the rss/atom feeds:
<http://clc-wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=rss>
<http://clc-wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=atom>

I haven't used a proper rss reader to view them, but their xml view seems
complete - diffs are included.

[...] Here's a suggestion for you - pop over to
http://www.cpax.org.uk/prg/portable/c/resources.php and steal the entire
page. (Make sure you read it over, though, since some of it won't
survive a change of ownership and will need editing.)


Nice; will copy relevant content.
* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson
agree that it fairly describes the newsgroup.


I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem
to think he is), his signal-to-noise ratio is way too low.


It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).

--
http://members.dodo.com.au/~netocrat
Jan 14 '06 #215
In article <dq**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Kenny McCormack said:
Just out curiosity, what is your definition of "troll"? What would I have
to do or not do to qualify?


Don't worry about it; you're doing just fine.


Your previous post left it unclear whether you thought I was or not.

Jan 14 '06 #216
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
Let us know if you find a deficiency in the rss/atom feeds:
<http://clc-
wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=rss
<http://clc-
wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=ato
m

I just tried the RSS feed in NetNewsWire (Mac OS X) and it seems
to work fine.
I haven't used a proper rss reader to view them, but their xml view seems
complete - diffs are included.


It looks find from here.

BTW, thank you for going to the trouble of putting this up. I
have high hopes for it.

Category suggestion: Homework problems. :-)
I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem
to think he is), his signal-to-noise ratio is way too low.


It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).


I understand your point. Just keep in mind that contrary to
popular belief, there *are* some insurmountable problems.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 14 '06 #217
Netocrat said:
On Sat, 14 Jan 2006 14:16:57 +0000, Richard Heathfield wrote:
Netocrat said:
On Sat, 14 Jan 2006 06:58:42 +0000, Richard Heathfield wrote:
Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)
Oh, I don't mind sticking my oar in, as long as I don't have to get my
hands dirty. :-)


Let's keep things clean then - starting with a ban on offensive language.


Excellent idea. Incidentally, I'm curious to know whether you thought
anything in my reply offensive. I don't recall whether you are a native
English speaker, so, in case you weren't aware of it, "to stick one's oar
in" is a conventional English idiom, meaning "to interpose when not asked",
according to my dictionary. A vicar could happily use it at a Mothers'
Union meeting, without blushing.

<snip>
If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).


That could take a while. (If it's any help, most of us here are pretty good
at disagreeing!)

--
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)
Jan 14 '06 #218
Kenny McCormack said:
In article <dq**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
Kenny McCormack said:
Just out curiosity, what is your definition of "troll"? What would I
have to do or not do to qualify?


Don't worry about it; you're doing just fine.


Your previous post left it unclear whether you thought I was or not.


Yes, that's right; it did.

--
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)
Jan 14 '06 #219
On Sat, 14 Jan 2006 17:07:21 +0000, Richard Heathfield wrote:
Netocrat said:
On Sat, 14 Jan 2006 14:16:57 +0000, Richard Heathfield wrote: [...]
Oh, I don't mind sticking my oar in, as long as I don't have to get my
hands dirty. :-)


Let's keep things clean then - starting with a ban on offensive
language.


Excellent idea. Incidentally, I'm curious to know whether you thought
anything in my reply offensive.


Not at all. It was a case of one idea leading to another:
hands-not-dirty => keep-things-clean => ban-unclean-language.

I also understand that you have a concern to avoid unclean language, so it
seemed appropriate.

[...]
--
http://members.dodo.com.au/~netocrat
Jan 14 '06 #220
Richard Heathfield wrote:
Netocrat said:
.... snip ...
Here's a suggestion for you - pop over to
http://www.cpax.org.uk/prg/portable/c/resources.php and steal
the entire page. (Make sure you read it over, though, since some
of it won't survive a change of ownership and will need
editing.)
*
<http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith
Thompson agree that it fairly describes the newsgroup.


I fail to see how Kenny McCormack's opinion is relevant, since
it's abundantly clear that, even if he isn't a troll (which most
of us seem to think he is), his signal-to-noise ratio is way too
low.


Is he mucking about here? He won't be seen unless somebody feeds him.

--
"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/>
Jan 15 '06 #221
Netocrat wrote:
On Sat, 14 Jan 2006 17:07:21 +0000, Richard Heathfield wrote:
Netocrat said:

[...]


I really want to thank you (all) for the depth of thought you're putting
into the clc-wiki's structure. I feel this is extremely important and
am very excited about the project. I'm also very glad to see that other
knowledgeable regulars are taking an interest in contributing.

Maybe a new thread should be started for "all things wiki", in order to
keep the discussion in the fore-front as well as enable the "enticement"
for others to participate. I look forward to the possibilities.

Just think that eventually this will help to further decrease the common
explanations that are frequently given by the group... The ones I'm sure
the regulars are tired of. A wiki with a very _well thought out_ and
_organized_ structure will be fantastic.

If only there was such consideration by all document developers (hint: a
standard per se), The OpenSource environment would be a much, much
better place.

Many thanks from a diligent learner,

Dieter
Jan 15 '06 #222
Netocrat wrote:
On Sat, 14 Jan 2006 17:07:21 +0000, Richard Heathfield wrote:
Netocrat said:

[...]


I really want to thank you (all) for the depth of thought you're putting
into the clc-wiki's structure. I feel this is extremely important and
am very excited about the project. I'm also very glad to see that other
knowledgeable regulars are taking an interest in contributing.

Maybe a new thread should be started for "all things wiki", in order to
keep the discussion in the fore-front as well as enable the "enticement"
for others to participate. I look forward to the possibilities.

Just think that eventually this will help to further decrease the common
explanations that are frequently given by the group... The ones I'm sure
the regulars are tired of. A wiki with a very _well thought out_ and
_organized_ structure will be fantastic.

If only there was such consideration by all document developers (hint: a
standard per se), The OpenSource environment would be a much, much
better place.

Many thanks from a diligent learner,

Dieter
Jan 15 '06 #223
Netocrat wrote:
On Sat, 14 Jan 2006 17:07:21 +0000, Richard Heathfield wrote:
Netocrat said:

[...]


I really want to thank you (all) for the depth of thought you're putting
into the clc-wiki's structure. I feel this is extremely important and
am very excited about the project. I'm also very glad to see that other
knowledgeable regulars are taking an interest in contributing.

Maybe a new thread should be started for "all things wiki", in order to
keep the discussion in the fore-front as well as enable the "enticement"
for others to participate. I look forward to the possibilities.

Just think that eventually this will help to further decrease the common
explanations that are frequently given by the group... The ones I'm sure
the regulars are tired of. A wiki with a very _well thought out_ and
_organized_ structure will be fantastic.

If only there was such consideration by all document developers (hint: a
standard per se), The OpenSource environment would be a much, much
better place.

Many thanks from a diligent learner,

Dieter
Jan 15 '06 #224
On Sat, 14 Jan 2006 05:50:05 GMT, Netocrat <ne******@dodo.com.au>
wrote:
This reply was delayed as I wanted to complete some development on the
wiki and set up a generic domain name before responding to Steve's post.
The wiki's now accessible through clc-wiki.net.


Wow. Thank you, thank you. A fantastic beginning.

One comment from my 2-minute look at the site - I find it slightly
disconcerting to have the little "link" symbol embedded in code, but
the link for keywords is otherwise an excellent idea.

--
Al Balmer
Sun City, AZ
Jan 17 '06 #225
On Tue, 17 Jan 2006 09:01:53 -0700, Al Balmer wrote: [...]
One comment from my 2-minute look at the [clc wiki] - I find it slightly
disconcerting to have the little "link" symbol embedded in code, but the
link for keywords is otherwise an excellent idea.


Agreed - I noticed that briefly a while ago but since you mention it, it's
been fixed. The Geshi syntax highlighting extension for the wiki was
Flash's find, and the links it generates are as you write a great idea -
it would be even better if it included all of the standard functions for
linking rather than the scant few that it does. Perhaps in future the wiki
will have its own set of descriptions of all standard functions that can
be internally linked to.

Review guidelines for C code published on the wiki have now been drafted,
along with templates to provide a (typically one-line) summary below each
block of code indicating its review status, original author and related
information:
<http://clc-wiki.net/wiki/Code_Reviews_%28for_this_wiki%29>
<http://clc-wiki.net/wiki/Help:Editing#C_Code>

Comments on these guidelines are welcome, particularly from anyone
interested in reviewing code on the wiki and anyone who has already
contributed code that's hosted on the wiki. No code has yet been reviewed
under these guidelines, nor has the summary line yet been used other than
for examples.

There's also been a suggestion that C code published on the wiki be
consistent in style, and that the style most likely to be universally
acceptable is K&R. Comments on this are welcome, recognising that the
issue of style is touchy.

The voting extension has also received a bit of a work-out, in the process
uncovering a subtle issue that required manual correction of the logged
eligible voter counts, although it didn't actually invalidate the tallying
process. The fix is being worked on.

The results[*] of the elections don't have great significance whilst edits
on the wiki are open and no group-reviewed-stable-page functionality yet
exists, although the title "editor" is currently equivalent to inclusion
in the wiki group "sysop" and includes a few extra capabilities such as
ability to block vandals by IP/name (along with voting of course).
[*] <http://clc-wiki.net/mediawiki/index.php?title=Special:Group_Decisions>

--
http://members.dodo.com.au/~netocrat
Jan 21 '06 #226
Netocrat said:
There's also been a suggestion that C code published on the wiki be
consistent in style, and that the style most likely to be universally
acceptable is K&R.


K&R style has the same probability of universal acceptance as all other
styles, i.e. 0.

--
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)
Jan 21 '06 #227
Richard Heathfield wrote:

Netocrat said:
There's also been a suggestion that C code published on the wiki be
consistent in style,
and that the style most likely to be universally
acceptable is K&R.


K&R style has the same probability of universal
acceptance as all other
styles, i.e. 0.


Indian Hill!

--
pete
Jan 21 '06 #228
On Sat, 21 Jan 2006 04:01:50 +0000, pete wrote:
Richard Heathfield wrote:
Netocrat said:
> There's also been a suggestion that C code published on the wiki be
> consistent in style,
> and that the style most likely to be universally acceptable is K&R.
K&R style has the same probability of universal acceptance as all other
styles, i.e. 0.


'Universally' was a poor choice there.

Disclosure: K&R is the style I first (implicitly - not necessarily
completely or accurately) learnt and it's still my preferred style. The
suggestion came from two other people though.

The reason I think it's likely to be most acceptable is that it was
developed by the founders of the language. Someone with a mind to
architect a programming language as successful as C is likely to make a
good job of an accompanying style. Given that style is so subjective, the
property "given birth to alongside the language and endorsed by its
parents" is a pretty objective basis for preference (unless there's
another style I don't know of with that property).

Would you suggest leaving the style guidelines at "consistent"?
Indian Hill!


A close relative of K&R style, but more focused on what rather than how,
yes?

--
http://members.dodo.com.au/~netocrat
Jan 21 '06 #229
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
On Sat, 21 Jan 2006 04:01:50 +0000, pete wrote:
Richard Heathfield wrote:
Netocrat said:

There's also been a suggestion that C code published on the wiki be
consistent in style,
and that the style most likely to be universally acceptable is K&R.

K&R style has the same probability of universal acceptance as all other
styles, i.e. 0.
'Universally' was a poor choice there.

Disclosure: K&R is the style I first (implicitly - not necessarily
completely or accurately) learnt and it's still my preferred style. The
suggestion came from two other people though.


My preference is closer to Allman style. I've been using large
monitors for long enough not to worry about vertical whitespace
much. Plus, I try not to write functions that are hundreds of
lines in length.

Finally, gnu indent is a lovely tool, freely available, so the
issue is pretty much moot anyway.
Indian Hill!


A close relative of K&R style, but more focused on what rather than how,
yes?


Mainly known for it's silly indenting of the braces, instead of
what's inside them.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 21 '06 #230
Randy Howard wrote:
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
On Sat, 21 Jan 2006 04:01:50 +0000, pete wrote:
Richard Heathfield wrote:
Netocrat said:

> There's also been a suggestion that C code published on the wiki be
> consistent in style,
> and that the style most likely to be universally acceptable is K&R.
K&R style has the same probability of universal acceptance as all other
styles, i.e. 0. 'Universally' was a poor choice there.

Disclosure: K&R is the style I first (implicitly - not necessarily
completely or accurately) learnt and it's still my preferred style. The
suggestion came from two other people though.


My preference is closer to Allman style. I've been using large
monitors for long enough not to worry about vertical whitespace
much. Plus, I try not to write functions that are hundreds of
lines in length.


As one of the people who suggested K&R style I'll state here and now
that I'm not overly bothered about code style.
Finally, gnu indent is a lovely tool, freely available, so the
issue is pretty much moot anyway.


Indeed. I considered suggesting GNU Indent to force the code in to a
consistent style, but it took me less than 1 second to reject the idea.
However, thinking further, I wonder if it would be possible to give
people the option of having the code piped through indent for display in
the Wiki? Then, as long as someone can specify the style they like they
can have it! It would require a few tweaks here and there, but it should
be possible. Of course, there is always the question of finding the time
to do things.
Indian Hill!

A close relative of K&R style, but more focused on what rather than how,
yes?


Mainly known for it's silly indenting of the braces, instead of
what's inside them.


I've generally had to abide by whatever the company standard happened to
be so I've never bothered learning the names of styles.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #231
Netocrat wrote:
On Tue, 17 Jan 2006 09:01:53 -0700, Al Balmer wrote: [...]
One comment from my 2-minute look at the [clc wiki] - I find it slightly
disconcerting to have the little "link" symbol embedded in code, but the
link for keywords is otherwise an excellent idea.
Agreed - I noticed that briefly a while ago but since you mention it, it's
been fixed. The Geshi syntax highlighting extension for the wiki was
Flash's find, and the links it generates are as you write a great idea -
it would be even better if it included all of the standard functions for
linking rather than the scant few that it does. Perhaps in future the wiki
will have its own set of descriptions of all standard functions that can
be internally linked to.


I just had a look at the code behind it, and it looks to me to be easy
to set up the links to point anywhere we like (Netocrat, have a look in
c.php to see what I mean). Perhaps link to the Dinkumware site for the
library since Mr P.J. Plauger is a reliable source on such matters?

If there is any similarly good (and stable) site to reference for
keywords such as "switch" that would also be easy.

Note that Netocrat has a backup of the Wiki and we can make backups
available to others, so even if the host disappears (I get run over by a
bus, for example) this Wiki can live on.

<snip>
The voting extension has also received a bit of a work-out, in the process
uncovering a subtle issue that required manual correction of the logged
eligible voter counts, although it didn't actually invalidate the tallying
process. The fix is being worked on.

The results[*] of the elections don't have great significance whilst edits
on the wiki are open and no group-reviewed-stable-page functionality yet
exists, although the title "editor" is currently equivalent to inclusion
in the wiki group "sysop" and includes a few extra capabilities such as
ability to block vandals by IP/name (along with voting of course).

[*] <http://clc-wiki.net/mediawiki/index.php?title=Special:Group_Decisions>


You could have used the friendlier URL of
http://clc-wiki.net/wiki/Special:Group_Decisions
;-)
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #232
Randy Howard wrote:

<snip>
BTW, thank you for going to the trouble of putting this up.
No problem :-). I've learnt a lot from this group as I'm sure the others
involved have as well, and setting this up is an attempt to give
something back to the community and help others.
I have high hopes for it.
As do I. Checking my logs for the past week it's been accessed from 143
different IP addresses (excluding spiders), people have followed links
to it from webmail systems and people are following links to it from
Google groups.
Category suggestion: Homework problems. :-)


You mean a set of sensible questions for tutors to set? ;-)

<snip>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #233
Al Balmer wrote:
On Sat, 14 Jan 2006 05:50:05 GMT, Netocrat <ne******@dodo.com.au>
wrote:
This reply was delayed as I wanted to complete some development on the
wiki and set up a generic domain name before responding to Steve's post.
The wiki's now accessible through clc-wiki.net.
Wow. Thank you, thank you. A fantastic beginning.


I'm glad you think so :-)
One comment from my 2-minute look at the site - I find it slightly
disconcerting to have the little "link" symbol embedded in code, but
the link for keywords is otherwise an excellent idea.


Well, the link symbol has been sorted, and it will be easy to add more
automatic linking from the C code as/when we select reliable references
to link to.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #234
Dieter wrote:

<snip clc-wiki discssion>
Many thanks from a diligent learner,


Thank you. It's nice to hear occasionally from the target audience that
one's work is appreciated.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #235
Flash Gordon wrote:
Randy Howard wrote:

<snip>
Category suggestion: Homework problems. :-)


You mean a set of sensible questions for tutors to set? ;-)


Among other things... However, I have given
"non-real-life" C homework to students to in order
to drive home a certain aspect of a lesson.
Only when we discussed possible solutions the real
life aspects came in.

Primarily: How to ask about homework questions.
There was a discussion within the last months where
Chris Hills brought up a "template":
Start at <YM**************@phaedsys.demon.co.uk>
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jan 21 '06 #236
Randy Howard wrote:
Netocrat wrote
pete wrote:

.... snip ...

Disclosure: K&R is the style I first (implicitly - not necessarily
completely or accurately) learnt and it's still my preferred style.
The suggestion came from two other people though.


My preference is closer to Allman style. I've been using large
monitors for long enough not to worry about vertical whitespace
much. Plus, I try not to write functions that are hundreds of
lines in length.

Finally, gnu indent is a lovely tool, freely available, so the
issue is pretty much moot anyway.
Indian Hill!


A close relative of K&R style, but more focused on what rather
than how, yes?


Mainly known for it's silly indenting of the braces, instead of
what's inside them.


Whee - style war. Is this a private fight or can anybody join in?

--
"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/>

Jan 22 '06 #237
[c.l.c wiki style guidelines]
On Sat, 21 Jan 2006 19:25:15 +0000, Flash Gordon wrote:
Randy Howard wrote:
My preference is closer to Allman style. I've been using large
monitors for long enough not to worry about vertical whitespace much.
Plus, I try not to write functions that are hundreds of lines in
length.
As one of the people who suggested K&R style I'll state here and now
that I'm not overly bothered about code style.
Finally, gnu indent is a lovely tool, freely available, so the issue is
pretty much moot anyway.


Indeed. I considered suggesting GNU Indent to force the code in to a
consistent style, but it took me less than 1 second to reject the idea.
However, thinking further, I wonder if it would be possible to give
people the option of having the code piped through indent for display in
the Wiki? Then, as long as someone can specify the style they like they
can have it! It would require a few tweaks here and there, but it should
be possible. Of course, there is always the question of finding the time
to do things.


On-the-fly conversion using an indent tool would be fine as an option but
it could also remove deliberately encoded information, so conversion
shouldn't be the default.

Code on the wiki should conform to a single style, whether that's as
specific as K&R, Allman, Indian Hill, or a collaboratively specified c.l.c
wiki style, or something general like "readable and consistent within each
contribution". I can see arguments all ways but a more specific style
across the wiki would be most readable.
Randy Howard wrote:
Netocrat wrote
On Sat, 21 Jan 2006 04:01:50 +0000, pete wrote:
Indian Hill!
A close relative of K&R style, but more focused on what rather than
how, yes?


Mainly known for it's silly indenting of the braces, instead of what's
inside them.


I thought it used K&R brace style and I took pete's recommendation as
seriously intended.

[...]
--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #238
Flash Gordon wrote:
Randy Howard wrote:

<snip>
BTW, thank you for going to the trouble of putting this up.


No problem :-). I've learnt a lot from this group as I'm sure the
others involved have as well, and setting this up is an attempt
to give something back to the community and help others.
I have high hopes for it.


As do I. Checking my logs for the past week it's been accessed
from 143 different IP addresses (excluding spiders), people have
followed links to it from webmail systems and people are following
links to it from Google groups.


I accessed it by typing "clc-wiki.net" into Firefox. Looks clean.
I created an account and left. :-)

--
"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/>
Jan 22 '06 #239
On Sat, 14 Jan 2006 16:56:38 +0000, Randy Howard wrote:
Netocrat wrote [...]
Let us know if you find a deficiency in the rss/atom feeds:

I just tried the RSS feed in NetNewsWire (Mac OS X) and it seems
to work fine.


Thanks for the confirmation - I've also verified it with a Linux reader.

[...] BTW, thank you for going to the trouble of putting this up. I have high
hopes for it.


There's definitely heaps of potential. The posters to this group have
given me a lot of insight into C so it's something that I find worthwhile.

[...]
I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem
to think he is), his signal-to-noise ratio is way too low.


It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree
ends up agreeing, then the chances that you've written something with
balance are pretty good (disagreement wouldn't necessarily mean that
the page was unbalanced).


I understand your point. Just keep in mind that contrary to popular
belief, there *are* some insurmountable problems.


If we find consensus on a common style for C code on the wiki, will you
take that comment back? ;-)

--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #240
CBFalconer wrote
(in article <43***************@yahoo.com>):
Indian Hill!

A close relative of K&R style, but more focused on what rather
than how, yes?


Mainly known for it's silly indenting of the braces, instead of
what's inside them.


Whee - style war. Is this a private fight or can anybody join in?


Actually, I explicitly said upthread that it doesn't matter with
tools for reformatting being readily available, but if you feel
the need to argue about it anyway, be my guest. Who will you be
arguing with?
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 22 '06 #241
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
> Indian Hill!
A close relative of K&R style, but more focused on what rather than
how, yes?

Mainly known for it's silly indenting of the braces, instead of what's
inside them.


I thought it used K&R brace style and I took pete's recommendation as
seriously intended.


if (foo)
{
printf("foo detected\n");
}

Kind of strange to my eye.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 22 '06 #242
Flash Gordon wrote
(in article <qe************@news.flash-gordon.me.uk>):
Category suggestion: Homework problems. :-)


You mean a set of sensible questions for tutors to set? ;-)


Two variants possible (at least).

1) Questions that professors SHOULD NOT ask because asking them
proves that they don't understand their subject well enough. If
we can do anything to educate the educators, life will get
better down the road for people using software written by their
students. Yes, pie in the sky, but why not try?

2) A listing of questions that will not be answered in c.l.c,
because you are supposed to learn how on your own. then, you
can reply to the standard questions (reverse a string,
palindrome, etc, etc) by a simple link to the wiki. They might
actually learn something useful while visiting, even if they
don't find a compilable solution to their problem.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 22 '06 #243
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem
to think he is), his signal-to-noise ratio is way too low.

It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree
ends up agreeing, then the chances that you've written something with
balance are pretty good (disagreement wouldn't necessarily mean that
the page was unbalanced).


I understand your point. Just keep in mind that contrary to popular
belief, there *are* some insurmountable problems.


If we find consensus on a common style for C code on the wiki, will you
take that comment back? ;-)


A) I don't really care what formatting convention is used on the
wiki. I think my disagreement on what Indian Hill means as a
format is the source of others deciding I want to argue about
it. I do not, for the record.

B) No. Solving style issues on a web site, and making Kenny's
opinions relevant are two radically different problems. One is
analogous to O(n log n) and the other is NP complete.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
How 'bout them Horns?

Jan 22 '06 #244
On Sun, 22 Jan 2006 00:42:09 +0100, Michael Mair wrote:
Flash Gordon wrote:
Randy Howard wrote:
<snip>
Category suggestion: Homework problems. :-)


You mean a set of sensible questions for tutors to set? ;-)


Among other things... However, I have given "non-real-life" C homework
to students to in order to drive home a certain aspect of a lesson. Only
when we discussed possible solutions the real life aspects came in.


A repository of insight-based problems would be useful.
Primarily: How to ask about homework questions. There was a discussion
within the last months where Chris Hills brought up a "template":
Start at <YM**************@phaedsys.demon.co.uk>


I remember reading that and have added it as a reference post (link to
Google archive) to the introductory comp.lang.c page on the wiki.
Yourself, Chris Hills, Randy Howard or anyone else could import it into
the wiki under a new "Homework Problems" category if you'd like to expand
on it.

--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #245
Randy Howard wrote:
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
>> Indian Hill!
> A close relative of K&R style, but more focused on what rather than >>>> how, yes?
Mainly known for it's silly indenting of the braces, instead of

what's >>> inside them.

I thought it used K&R brace style and I took pete's recommendation
as seriously intended.


if (foo)
{
printf("foo detected\n");
}

Kind of strange to my eye.


This is my favored style. The braces, like the statements, are part of
the same code entity, the block. It makes sense for them to be aligned.
They aren't part of the if().

Not all that many people agree.
Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Jan 22 '06 #246
On Sun, 22 Jan 2006 03:49:26 +0000, Randy Howard wrote:
Flash Gordon wrote
(in article <qe************@news.flash-gordon.me.uk>):
Category suggestion: Homework problems. :-)
You mean a set of sensible questions for tutors to set? ;-)


Two variants possible (at least).

1) Questions that professors SHOULD NOT ask because asking them proves
that they don't understand their subject well enough. If we can do
anything to educate the educators, life will get better down the road
for people using software written by their students. Yes, pie in the
sky, but why not try?


So they could be used by students to verify whether their instructors are
up to scratch as well as by instructors to skill up.
2) A listing of questions that will not be answered in c.l.c, because
you are supposed to learn how on your own. then, you can reply to the
standard questions (reverse a string, palindrome, etc, etc) by a simple
link to the wiki. They might actually learn something useful while
visiting, even if they don't find a compilable solution to their
problem.


A "common homework problem - do not solve" list seems like a good idea -
source code for those problems would never be published on the wiki, but
hints and suggestions could be.

--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #247
On Sun, 22 Jan 2006 03:52:15 +0000, Randy Howard wrote:
[...]
A) I don't really care what formatting convention is used on the wiki. I
think my disagreement on what Indian Hill means as a format is the
source of others deciding I want to argue about it. I do not, for the
record.


We don't have to argue, but if you, pete and I are using different
understandings of what that style means, we're not communicating
effectively.

I've never coded to Indian Hill style guidelines before so I'm basing my
understanding on this:
<http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html>.

[...]
--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #248
On Sun, 22 Jan 2006 05:01:47 +0000, Default User wrote:
Randy Howard wrote:
Netocrat wrote
(in article <pa****************************@dodo.com.au>):
>>>>> Indian Hill!
>>>> A close relative of K&R style, but more focused on what rather
>>>> than how, yes?
>>>
>>> Mainly known for it's silly indenting of the braces, instead of
>>> what's inside them.
>
> I thought it used K&R brace style and I took pete's recommendation as
> seriously intended.
if (foo)
{
printf("foo detected\n");
}

Kind of strange to my eye.


I don't see anything intrinsically wrong with it, but I'm not accustomed
to it either. According to the Jargon file, that's Whitesmiths style:
<http://www.catb.org/~esr/jargon/html/I/indent-style.html>. It may be
part of other styles or known by other names.
This is my favored style. The braces, like the statements, are part of
the same code entity, the block. It makes sense for them to be aligned.
They aren't part of the if().

Not all that many people agree.


I don't think the justification you give has any more or less objective
weight than saying for another alignment that "the braces delimit the
block, and should be distinct from it". Bracing style is probably a
personal choice in the absence of other requirements.

--
http://members.dodo.com.au/~netocrat
Jan 22 '06 #249
Randy Howard wrote:
Netocrat wrote
>> Indian Hill!
> A close relative of K&R style, but more focused on what rather
> than how, yes?

Mainly known for it's silly indenting of the braces, instead of
what's inside them.


I thought it used K&R brace style and I took pete's recommendation
as seriously intended.


if (foo)
{
printf("foo detected\n");
}

Kind of strange to my eye.


Mine too. However it actually makes a sort of sense. The if
statement controls stuff, and all that stuff is indented. I use
exactly this sort of thing in Pascal, where things may read:

IF whatever THEN BEGIN
stuff;
and more stuff; END;
still more stuff.

Somebody in this thread has been stripping attributions of quoted
material. You know who you are. Please don't.

--
"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/>
Jan 22 '06 #250

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: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

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.