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

[Randy Howard]

Netocrat wrote
(in article <pa****************************@dodo.com.au>):

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:

Ack, you're right. I was mixing up the two in my mind. Sorry
about confusing the issue. :-(
--
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?

[Randy Howard]

CBFalconer wrote
(in article <43***************@yahoo.com>):

Randy Howard wrote:

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.

It's admittedly been a while since I did Pascal ('88 or so?),
but wouldn't the actual analogy be:

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

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

[Malcolm]

"Netocrat" <ne******@dodo.com.au> wrote

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.

Good idea.

One problem is that we should discourage newbies from diving into a question
and simply writing code. Normally it is best to plan first, and get advice
before you start coding, rather than make a hash of things and then get a
helper to patch things up.
Unfortunately that makes it too easy for someone who has no intention of
putting any effort in to ask for help, in the hope of getting a working
program back. So most regs ask for an attempted program.

A wiki with homework hints would sove this.

[pete]

Netocrat wrote:

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.
The brace style is a little different and I was serious.

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.

/* This is Indian Hill */

if (expr) {
statement;
} else {
statement;
statement;
}

http://www.psgd.org/paul/docs/cstyle/cstyle09.htm
http://www.psgd.org/paul/docs/cstyle/cstyle.htm
http://www.google.com/search?hl=en&i...ill%22+C+style

--
pete

[pete]

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.

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.

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

It's when you have a textually too long expression
that Indian Hill style is like:
if (expression ...................
&& ......................)
{
statement;
}

--
pete

[CBFalconer]

Randy Howard wrote:

CBFalconer wrote

Randy Howard wrote:

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.

It's admittedly been a while since I did Pascal ('88 or so?),
but wouldn't the actual analogy be:

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

Yup. But in both languages my objective is clarity consumate with
conservation of vertical space. Thus I also use:

if (whatever) {
stuff;
and more stuff;
}
still more stuff.

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

[Joe Wright]

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.

Strange indeed. I would write it..

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

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Default User]

Netocrat wrote:

On Sun, 22 Jan 2006 05:01:47 +0000, Default User wrote:

Randy Howard wrote: 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.

Certainly, that's why there are personal preferences. I had
independently developed Whitesmith's on my own. In some of my early
projects, I'd use a ruler to check for misaligned stuff on printouts,
so I found it easier to have the braces part of the block I was
checking.

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Default User]

pete wrote:

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.

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.

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

Yeah, I didn't notice what he called it. The style I use is called
Whitesmith's. I think that was the place Plaugher used to work.

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Default User]

CBFalconer wrote:

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.

The theory behind Whitesmith's is that stuff between braces is a
compound statement. If you'd indent a single statement, why not a
compound.

However, trying to apply logic isn't going to convince many people. You
like what you like. The most important thing on any cooperative project
is to pick a style and make it consistent. If that happens to be OTBS,
that would be fine, even though not a style I've used in 20 years.

It's easier these days with indenters and text editors that you can set
for auto-indent in various styles.

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Jordan Abel]

On 2006-01-22, Netocrat <ne******@dodo.com.au> wrote:

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.

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]

On 2006-01-22, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-22, Netocrat <ne******@dodo.com.au> wrote:

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.

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]

On Sat, 21 Jan 2006 20:20:39 +0000, Flash Gordon wrote:
[...]

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.

[...] Netocrat wrote:

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

[...]
--
http://members.dodo.com.au/~netocrat

[Netocrat]

On Sun, 22 Jan 2006 20:04:05 +0000, Jordan Abel wrote:

On 2006-01-22, Jordan Abel <ra*******@gmail.com> wrote: [...]

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:
<pa****************************@dodo.com.au>, 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
post: <dp**********@eskinews.eskimo.com>.
[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").

--
http://members.dodo.com.au/~netocrat

[CBFalconer]

Jordan Abel wrote:

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

[Al Balmer]

On Sun, 22 Jan 2006 11:49:20 GMT, pete <pf*****@mindspring.com> wrote:

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.

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.

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

[Michael Wojcik]

In article <pa****************************@dodo.com.au>, Netocrat <ne******@dodo.com.au> writes:

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.

--
Michael Wojcik mi************@microfocus.com

Shakespeare writes bombast and knows it; Mr Thomas writes bombast and
doesn't. That is the difference. -- Geoffrey Johnson

[Jordan Abel]

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On Sun, 22 Jan 2006 11:49:20 GMT, pete <pf*****@mindspring.com> wrote:

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.

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.

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.

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]

Michael Wojcik wrote:

...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
sc*@eskimo.com

63654887216215379650310989701245920210972861517262 63141
6546461340015873146324009591872241875120686

[Netocrat]

On Mon, 23 Jan 2006 16:16:11 +0000, Michael Wojcik wrote:

In article <pa****************************@dodo.com.au>, Netocrat
<ne******@dodo.com.au> writes:

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.

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

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.

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.

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.

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.

--
http://members.dodo.com.au/~netocrat

[Randy Howard]

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

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

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

[Al Balmer]

On 23 Jan 2006 16:53:40 GMT, Jordan Abel <ra*******@gmail.com> 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.
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)
{

[Al Balmer]

On Mon, 23 Jan 2006 22:14:57 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

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

--
Al Balmer
Sun City, AZ

[Ian Collins]

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.

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.

--
Ian Collins.

[Randy Howard]

Al Balmer wrote
(in article <qt********************************@4ax.com>):

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.

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

[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
(in article <5r********************@comcast.com>):

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

[Jordan Abel]

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On 23 Jan 2006 16:53:40 GMT, Jordan Abel <ra*******@gmail.com> 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.

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]

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On Mon, 23 Jan 2006 22:14:57 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

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]

Jordan Abel wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:

<snip>

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?

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Jordan Abel wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On 23 Jan 2006 16:53:40 GMT, Jordan Abel <ra*******@gmail.com> wrote: <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(/.

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.

ctags/etags help the editor...
vi, Emacs, NEdit and others can handle them.
Guessing function identifiers works only within certain
restrictions if one does not want to parse the whole
source file, exclude string literals and comments, etc.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Chris Smith]

Michael Mair <Mi**********@invalid.invalid> wrote:

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

Where did we jump from "is it even possible to ..." to "is it even
possible using regular expressions to ..."?

In conjunction with ctags, which uses a parser more powerful than
regular expressions, vi can do a lot of things that regular expressions
can't do.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Netocrat]

On Tue, 24 Jan 2006 02:52:10 +0000, Randy Howard wrote:

Dieter wrote (in article <5r********************@comcast.com>):

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.
In an earlier post I referenced a template for summary lines below code,
the details and usage of which are explained on the Help:Editing page
(also accessible through the "Editing help" link whilst editing pages).

The template suggests four classifications for code blocks:
* full program: will compile to executable as-is
* compilable unit: will compile to a library as-is
* complete snippet: will compile when inserted as-is into an appropriate
location in other code
* incomplete snippet: cannot be made to compile as-is - e.g. because it
contains ellipses indicating "fill in appropriate bits here"

Perhaps a fifth is necessary:
* base program: contains the main() function and will compile as-is to
executable when linked with non-standard but wiki-defined library units
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.

The problem with that is that it wouldn't stop people from posting to the
continuing discussions in this thread, and having two disparate threads
would only make following the discussion harder. For most purposes, a new
thread /was/ started when the subject header changed.

Does your newsreader not allow you to filter on subject header? Actually,
as I recall I found that fraught in Thunderbird - it lost threading
ability when filtering - one of the reasons I switched to Pan.
I suggest discussion of it on the wiki itself instead.

Yes, more specific discussion should focus within the talk page
associated with each content page, and for more general
discussion/suggestions, the "Planning:Public comments" page exists.

I've mostly tried to limit my posts here to information about additions
and changes that someone previously not interested in the wiki might like
to know about, but I've been more willing to engage in specific discussion
because I don't believe that many people are actively monitoring the wiki.

For anyone wanting to rejoin a specific style discussion on the wiki,
there's a summary of the relevant parts of this thread on the discussion
page for the "Code Style Guidelines (for this wiki)" page:
<http://clc-wiki.net/wiki/Talk:Code_Style_Guidelines_%28for_this_wiki%29>

--
http://members.dodo.com.au/~netocrat

[Al Balmer]

On 24 Jan 2006 03:35:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On Mon, 23 Jan 2006 22:14:57 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

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

The compiler does it all the time ;-)

--
Al Balmer
Sun City, AZ

[Jordan Abel]

On 2006-01-24, Chris Smith <cd*****@twu.net> wrote:

Michael Mair <Mi**********@invalid.invalid> wrote:

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

Where did we jump from "is it even possible to ..." to "is it even
possible using regular expressions to ..."?

In conjunction with ctags, which uses a parser more powerful than
regular expressions, vi can do a lot of things that regular expressions
can't do.

Can straight vi even use ctags? or are you thinking of vim?

[i don't even know how to use ctags anyway]

[CBFalconer]

Michael Mair wrote:

.... snip all ...

Your clock is misset. Your article got here about 3 hours before
you wrote it :-)

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

[Al Balmer]

On 24 Jan 2006 03:24:15 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On 23 Jan 2006 16:53:40 GMT, Jordan Abel <ra*******@gmail.com> 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.

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.

? You asked "How else would you ...", and I gave an example. The
indentation of the type was the only thing I was questioning - I've
seen the rest before.

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?

I use Visual Slickedit, but of course it isn't the only editor that
has this kind of capability. It doesn't produce false hits, but even
if it did, I can't see that as a serious problem for an editor.
Anyway, if i'm
looking for a function definition in a large source tree, it's nice to
be able to use grep.

I prefer to right click and choose "Go to Definition" :-)

It's also very nice to right click and choose "Go to Reference", which
gives me all the references to a function (or other token) in the
workspace (which can be the entire source tree.)

I know enough vi to get by if needed, but for everyday work, I'm
definitely a fan of modern editors.

--
Al Balmer
Sun City, AZ

[Jordan Abel]

On 2006-01-24, Al Balmer <al******@att.net> wrote:

On 24 Jan 2006 03:35:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:

On Mon, 23 Jan 2006 22:14:57 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

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

The compiler does it all the time ;-)

With only a single line of context? [limitations of both vi and grep]

[Randy Howard]

Jordan Abel wrote
(in article <sl***********************@random.yi.org>):

On 2006-01-24, Chris Smith <cd*****@twu.net> wrote:

Michael Mair <Mi**********@invalid.invalid> wrote:

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

Where did we jump from "is it even possible to ..." to "is it even
possible using regular expressions to ..."?

In conjunction with ctags, which uses a parser more powerful than
regular expressions, vi can do a lot of things that regular expressions
can't do.

Can straight vi even use ctags? or are you thinking of vim?

vi could use ctags 20 years ago.
--
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?

[Chris Smith]

Jordan Abel <ra*******@gmail.com> wrote:

Can straight vi even use ctags? or are you thinking of vim?

I imagine that depends on what you mean by straight vi. ctags support
is certainly not limited to vim. Most vi implementations that I've come
across will use a tags file.

A list of ctags tools is at http://ctags.sourceforge.net/tools.html,
though the list is incomplete (for example, it doesn't include standard
GNU pager called less; and there are web sites that suggest some
versions of more may use tags files as well).

In any case, this is quickly drifting off topic for the group...

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Michael Mair]

CBFalconer wrote:

Michael Mair wrote:

... snip all ...

Your clock is misset. Your article got here about 3 hours before
you wrote it :-)

??? Time zone seems correct, time seems correct...
Did I miss something?

Puzzled
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Chris Smith wrote:

Michael Mair <Mi**********@invalid.invalid> wrote:

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

Where did we jump from "is it even possible to ..." to "is it even
possible using regular expressions to ..."?

In conjunction with ctags, which uses a parser more powerful than
regular expressions, vi can do a lot of things that regular expressions
can't do.

See my other reply (where I mention ctags in conjunction with vi).
The thing is, we were talking about regular expressions and searching
for ^ followed by an identifier upthread.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[CBFalconer]

Michael Mair wrote:

CBFalconer wrote:

Michael Mair wrote:

... snip all ...

Your clock is misset. Your article got here about 3 hours before
you wrote it :-)

??? Time zone seems correct, time seems correct...
Did I miss something?

This one seems ok. Maybe I added in place of subtracted?

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

[Richard Bos]

Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-24, Al Balmer <al******@att.net> wrote:

On 24 Jan 2006 03:35:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-23, Al Balmer <al******@att.net> wrote:
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?

The compiler does it all the time ;-)

With only a single line of context? [limitations of both vi and grep]

Get a real editor, then. Why should we suffer a braindead style of
declarations just because vi is barely better than EDLIN?

Richard

[Mark B]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43****************@news.xs4all.nl...

Jordan Abel <ra*******@gmail.com> wrote:

On 2006-01-24, Al Balmer <al******@att.net> wrote:

> On 24 Jan 2006 03:35:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:
>
>>On 2006-01-23, Al Balmer <al******@att.net> wrote:
>>> 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?
>
> The compiler does it all the time ;-)

With only a single line of context? [limitations of both vi and grep]

Get a real editor, then. Why should we suffer a braindead style of
declarations just because vi is barely better than EDLIN?

That 'braindead style' you speak of (relating to return type placement
at the start of a function definition) is very common practice, and may
be found in many 'style' guides. If you have man pages on your favorite
system, try typing 'man style' sometime and see what it says.

I personally place function type on a line by itself for aesthetic reasons
as my editor of choice (brief) can find the function and index it in a
routine tree regardless of whether or not the type is on the same line.
(I am however required to put the opening brace on the next line.)

As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so. What benefits are gained by putting the return type on the
same line? (other than the obvious: 1 less line of code to maintain) :-)

Mark

[Mark McIntyre]

On Wed, 25 Jan 2006 12:21:42 -0500, in comp.lang.c , "Mark B"
<so***@localbar.com> wrote:

That 'braindead style' you speak of (relating to return type placement
at the start of a function definition) is very common practice,
But only for historical reasons. Just because some people still wipe
their a*ses with leaves, doesn't mean you should stop buying bog
paper.
and may be found in many 'style' guides.
.... typically written by those of us who learned to programme on
PDP-11s and Z80s, and who had no choice but to use tools that today
seem barbaric..
As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so.
Sure, but again, who needs such "primitive" tools when sensible editor
suites can do this just as easily :-)
What benefits are gained by putting the return type on the
same line?

you avoid interminable arguments about bizarre style.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Ian Collins]

Mark McIntyre wrote:

As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so.

Sure, but again, who needs such "primitive" tools when sensible editor
suites can do this just as easily :-)

What if you wish to manipulate files outside of you editor?

--
Ian Collins.

[Richard Bos]

"Mark B" <so***@localbar.com> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43****************@news.xs4all.nl...

Jordan Abel <ra*******@gmail.com> wrote:

With only a single line of context? [limitations of both vi and grep]
Get a real editor, then. Why should we suffer a braindead style of
declarations just because vi is barely better than EDLIN?

That 'braindead style' you speak of (relating to return type placement
at the start of a function definition) is very common practice,

It is indeed very common in Ganoo circles. Many things that are common
amongst open sores adherents are popular for no good reason; this is one
of them.
and may
be found in many 'style' guides. If you have man pages on your favorite
system, try typing 'man style' sometime and see what it says.
"No manual entry for style."
As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so. What benefits are gained by putting the return type on the
same line?

It
is semantically sensible.

You
do not put the first word of a sentence on a new line, right?
Or
do you perhaps do that, as well?

Richard

[Richard Bos]

Ian Collins <ia******@hotmail.com> wrote:

Mark McIntyre wrote:

As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so.

Sure, but again, who needs such "primitive" tools when sensible editor
suites can do this just as easily :-)

What if you wish to manipulate files outside of you editor?

You learn to read.

Richard

[Al Balmer]

On Thu, 26 Jan 2006 13:29:05 +1300, Ian Collins <ia******@hotmail.com>
wrote:

Mark McIntyre wrote:

As someone else has already mentioned, type placement on a line
by itself allows grep to easily find a defintion when you're faced with
multiple source files (grep ^func *.c) so we can see a few benefits in
doing so.

Sure, but again, who needs such "primitive" tools when sensible editor
suites can do this just as easily :-)

What if you wish to manipulate files outside of you editor?

So, you locate your file with grep. What are you going to do with it?
Edit it with sed?

--
Al Balmer
Sun City, AZ