gets() - dangerous?

[Jordan Abel]

So they could be used by students to verify whether their instructors are
up to scratch as well as by instructors to skill up.


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.

speaking of "lists to be placed on the wiki" - anyone else think that
migrating the faq to the wiki [maybe as a "working, live copy", with the
'official' copy still at c-faq.org] might be a good idea?

 

[Jordan Abel]

So they could be used by students to verify whether their instructors are
up to scratch as well as by instructors to skill up.


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.

speaking of "lists to be placed on the wiki" - anyone else think that
migrating the faq to the wiki [maybe as a "working, live copy", with the
'official' copy still at c-faq.org] might be a good idea?

c-faq.com, rather - and, i meant only if proper permission is given, of
course [though, why doesn't the newsgroup have its own faq that isn't
"owned" by a specific person or company?]

 

[Netocrat]

]

I just had a look at the code behind [the wiki's on-the-fly C code
syntax highlighter], and it looks to me to be easy to set up the links
[to standard library function/keyword descriptions] 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?

I was going to suggest that too, but the Limited Access Notice intercepts
direct links.

[...]
The extension is lacking a protocol for informing nominees of nomination
and allowing them to decline. We'll hold off on using it again until a
protocol is worked out and we've confirmed that no one wants to belatedly
decline nomination.

[...]

 

[Netocrat]

speaking of "lists to be placed on the wiki" - anyone else think that
migrating the faq to the wiki [maybe as a "working, live copy", with the
'official' copy still at c-faq.org] might be a good idea?

A similar question was asked in the starting post of this sub-thread:
<[email protected]>, and similar ideas were
expressed in later posts. It's Steve Summit's call as to whether a scheme
like that's acceptable - he's put the majority of effort into the FAQ and
holds copyright on it. In any case, the wiki won't set up a competing
alternative, it'll have to be something cooperative as you suggest.

c-faq.com, rather - and, i meant only if proper permission is given, of
course

The question of permission and copyright was addressed in the follow-up

[though, why doesn't the newsgroup have its own faq that isn't
"owned" by a specific person or company?]

That question was raised and responded to in the original wiki thread
(google for "C FAQ wiki").

 

[CBFalconer]

.... snip ...

c-faq.com, rather - and, i meant only if proper permission is given,
of course [though, why doesn't the newsgroup have its own faq that
isn't "owned" by a specific person or company?]

Because Steve Summit has done an excellent job, and made his work
freely available to all of us. I'm sure he has retired in luxury
with the income it generates.

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

 

[Michael Wojcik]

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.

I'm not going to advocate for or against a particular style here, but
this argument seems very weak to me. I don't see any evidence to
support the thesis that a language designer is necessarily interested
in style in general.

Further, I don't see any basis for arguing that a language designer's
style preference has any objective weight. What makes a language's
developer any more of an authority on what constitutes a good style?
The only warrant for that claim seems to be one of authority by
association: the designer is an authority on the language, and hence
one on its proper use. There's no logical justification.

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

I don't think it's objective at all. The fact of its origin is, but
attachment to preference is not.

Would you suggest leaving the style guidelines at "consistent"?

I would, perhaps with suggestions such as moderate line length,
avoiding //-style comments, and avoiding tabs (or at least the mixing
of tabs and spaces for indentation). I'd be happier, personally, to
see no guidelines than to see too many. As with prose style, I
believe style guidelines are often counterproductive, leading to a
tiresome and sometimes awkward consistency for no sake but its own.

But in the end, it's the editors of the Wiki who are doing the work,
and the decision should be yours.

 

[Al Balmer]

Ordinary Indian Hill is like this:
if (expr) {
statement;
}

Actually, the Indian Hill reference seems to say to use whatever brace
style you like. They say the K&R style is preferred if you don't
already have a favorite.

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.

 

[Jordan Abel]

Actually, the Indian Hill reference seems to say to use whatever brace
style you like. They say the K&R style is preferred if you don't
already have a favorite.

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.

Well, that's for K&R type functions, not modern ones with prototypes.
how else would you break/indent that? [without changing the actual token
list being formatted]

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

 

[Steve Summit]

...this argument seems very weak to me. I don't see any evidence to
support the thesis that a language designer is necessarily interested
in style in general.

Well, we know that Brian Kernighan, at least, is *very*
interested in good style (though as I'll mention below, there's
much more to style than brace placement and indentation).

Further, I don't see any basis for arguing that a language designer's
style preference has any objective weight. What makes a language's
developer any more of an authority on what constitutes a good style?
The only warrant for that claim seems to be one of authority by
association: the designer is an authority on the language, and hence
one on its proper use. There's no logical justification.

There's really only one open question: should a large,
consistent, multi-author, public document such as a c.l.c. Wiki
display all its code samples using a single, consistent
indentation style? If the answer is "yes", then the answer
to the secondary question of "which style should we use?" is
obvious; there's no debate: just use K&R. Period. The rationale
is straightforward, and it's not unrelated to the argument just
above (the one you tried to dismiss for having "no logical
justification"): K&R style is, quite simply, the only style that
those multiple authors and editors will ever be able to agree on.
Period.

With that said, though, and as I've already hinted at above
(and in defense of the language designers of the world who,
you've suggested, aren't necessarily interested in good style):
it's important to point out that programming style has to do with
an awful lot more than just where the curly braces go. If you're
spending all your style time debating indentation rules and
imagining that once you've made a decision you'll have made great
progress, I'm afraid you're deluding and penalizing yourself,
because it means you're not paying attention to things that
matter even more, such as whether your variable names make sense,
and your expressions clearly show what they're computing, and
your control flow isn't tangled, and your functions are
well-modularized, and all that.

Steve Summit
(e-mail address removed)

6365488721621537965031098970124592021097286151726263141
6546461340015873146324009591872241875120686

 

[Netocrat]

I'm not going to advocate for or against a particular style here, but
this argument seems very weak to me. I don't see any evidence to
support the thesis that a language designer is necessarily interested in
style in general.

I was considering C more specifically than that. I've encountered many
comments on the white book, none of them negative much beyond "it's
probably not so appropriate for total beginners" or "it's very condensed
and requires much consideration". In particular, I've never encountered a
contradiction of the claim that - and have fairly often encountered the
claim itself - the book is elegant in its concise expression of C idiom.
"Elegant" and "idiom" are close relatives of "style", so a thesis that the
designer of C at least had a powerful sense for style, whether expressly
interested in it or not, seems reasonable to me.

Also the reasons behind C's success are as relevant as its success - in
particular the appropriateness of the choices made when developing the
language's model, which I'll take up below.

Further, I don't see any basis for arguing that a language designer's
style preference has any objective weight. What makes a language's
developer any more of an authority on what constitutes a good style? The
only warrant for that claim seems to be one of authority by association:
the designer is an authority on the language, and hence one on its
proper use. There's no logical justification.

Developing a style involves some of the same type of choices as developing
the language does, and someone with a particular talent for the latter -
as I'm arguing C's founders had - is likely to be skilled at the former,
and is also likely to have exercised that skill in the process of writing
a comprehensive tutorial on the language (the type of choices aren't
identical, but they're similar enough to presume a relationship).

I don't think it's objective at all. The fact of its origin is, but
attachment to preference is not.

I'm not claiming it's wholly objective, only that it's the most objective
basis I can find for choosing a shared style for a public repository - for
C in particular given the general respect for the discriminatory abilities
of its designers. If someone were to present a set of well-conducted
studies and metrics to show that another style was in general better, for
some reasonable definition of "better", then I'd reconsider.

I would, perhaps with suggestions such as moderate line length, avoiding
//-style comments, and avoiding tabs (or at least the mixing of tabs and
spaces for indentation). I'd be happier, personally, to see no
guidelines than to see too many. As with prose style, I believe style
guidelines are often counterproductive, leading to a tiresome and
sometimes awkward consistency for no sake but its own.

I appreciate that feedback. Steve Summit's comments - that there's more
to style than "where the curly braces go" - in his follow-up post suggest
a few other general style review guidelines such as "variable names should
be descriptive", "expressions should not be unnecessarily complex",
"control structures should be used with clarity as a goal and should not
obscure flow", etc.

The advantages of that choice are that it would avoid the need to
restructure most new and existing code, and it would be a style that far
more of us can agree on without compromising our personal styles.

The disadvantage is that C code across the Wiki would be - and already is
- quite inconsistent.

But in the end, it's the editors of the Wiki who are doing the work, and
the decision should be yours.

Any c.l.c reader is a potential editor, so some newsgroup discussion prior
to making a decision helps us make sure it's an appropriate one.

 

[Randy Howard]

Jordan Abel wrote

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.

[snip]

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

Bingo, been doing that (including the legacy declarations back
then) as shown above ever since I started using vi as a text
editor, oh, hmmm, 20+ years ago. Oh, and I'm a 3 space indenter
instead of 4.

Gee, I certainly hope the wiki is not going to try to get
everyone that reads c.l.c to agree on a style. hehe

 

[Al Balmer]

Well, that's for K&R type functions, not modern ones with prototypes.

I assumed that the first-line indentation would be the same
regardless.

how else would you break/indent that? [without changing the actual token
list being formatted]

I wouldn't.

Nothing wrong, imo, with

node_t *tail(node_t *nodep)
{
.
.
.
}

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

My editor can find functions without that much help. What's the
justification for the type being indented?

 

[Al Balmer]

Jordan Abel wrote

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.

[snip]

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

Bingo, been doing that (including the legacy declarations back
then) as shown above ever since I started using vi as a text
editor, oh, hmmm, 20+ years ago. Oh, and I'm a 3 space indenter
instead of 4.

Hmmm.... "As shown above" is not as written. Does your reader compress
spaces?

BTW, I think even vi can identify a function without needing it at the
beginning of the line. Can't it?

Gee, I certainly hope the wiki is not going to try to get
everyone that reads c.l.c to agree on a style. hehe

"To dream the impossible dream ..."

 

[Ian Collins]

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.

Well, that's for K&R type functions, not modern ones with prototypes.
how else would you break/indent that? [without changing the actual token
list being formatted]

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

It also make it easier to spot functions (and keep long lines in check)
where there is a long return type.

I must admit I found it strange when I first read it, but it's no my
default style.

 

[Randy Howard]

Al Balmer wrote

Hmmm.... "As shown above" is not as written. Does your reader compress
spaces?

It seems to at the start of a line only, which I hadn't noticed
before, and only when replying, apparently. Grrrr.

BTW, I think even vi can identify a function without needing it at the
beginning of the line. Can't it?

Probably, but /^funcname has been working for decades, and is so
ingrained in the muscle memory as to be automatic.

 

[Dieter]

Netocrat wrote:
[snip]

Any c.l.c reader is a potential editor, so some newsgroup discussion prior
to making a decision helps us make sure it's an appropriate one.

Two things:

1) Should all code examples be compilable? If this consideration hasn't
already been established, I'd like to suggest each example given _should
be_ compilable for the sake of clarity.

2) I, like others, am very interested in the progress, direction and
discussion of the clc-wiki, therefore I request a new thread started for
this sole purpose. Digging back in my newsreader, through 275 posts of
the "gets()-dangerous?" thread, is a hassle.

Thanks to all.
Dieter

 

[Randy Howard]

Dieter wrote

Netocrat wrote:
[snip]

Any c.l.c reader is a potential editor, so some newsgroup discussion prior
to making a decision helps us make sure it's an appropriate one.

Two things:

1) Should all code examples be compilable? If this consideration hasn't
already been established, I'd like to suggest each example given _should
be_ compilable for the sake of clarity.

2) I, like others, am very interested in the progress, direction and
discussion of the clc-wiki, therefore I request a new thread started for
this sole purpose. Digging back in my newsreader, through 275 posts of
the "gets()-dangerous?" thread, is a hassle.

I suggest discussion of it on the wiki itself instead.

 

[Jordan Abel]

Well, that's for K&R type functions, not modern ones with prototypes.

I assumed that the first-line indentation would be the same
regardless.

how else would you break/indent that? [without changing the actual token
list being formatted]

I wouldn't.

Nothing wrong, imo, with

node_t *tail(node_t *nodep)
{
.
.
.
}

Then your problem with the code you pasted goes beyond the indentation.

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

My editor can find functions without that much help. What's the
justification for the type being indented?

No idea. I actually don't like it, but that's the only change i'd make.

What editor do you use that can easily find the function [and no false
hits from calls to the function] with only the name? Anyway, if i'm
looking for a function definition in a large source tree, it's nice to
be able to use grep.

 

[Jordan Abel]

Jordan Abel wrote

What I find strange is the indented (on a separate line) function
types:

************
node_t *
tail(nodep)
node_t *nodep;
{
.
.
.
}
*************
I confess I didn't look up the rationale, because I can't imagine any
argument that would persuade me to like it.
[snip]

The reason for tail(nodep) being on a line by itself [and thus the
return type on a line before it] is to allow you to search for /^tail(/.

Bingo, been doing that (including the legacy declarations back
then) as shown above ever since I started using vi as a text
editor, oh, hmmm, 20+ years ago. Oh, and I'm a 3 space indenter
instead of 4.

Hmmm.... "As shown above" is not as written. Does your reader compress
spaces?

BTW, I think even vi can identify a function without needing it at the
beginning of the line. Can't it?

Is it even possible to "identify a function" and distinguish it from a
call to the function without doing something like putting it on the
beginning of the line?

 

[Michael Mair]

Is it even possible to "identify a function" and distinguish it from a
call to the function without doing something like putting it on the
beginning of the line?

Nope; regular expressions cannot "count parentheses", so finding
file level is restricted to guessing. One can look for the last
identifier before opening parens (not countable either...)
followed by everything but braces and closing parens, closing
parens, optional whitespace and opening braces. Add commented
out functions for fun.

Cheers
Michael