gets() - dangerous?

[Michael Mair]

On 23 Jan 2006 16:53:40 GMT, Jordan Abel <[email protected]> wrote:

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

 

[Chris Smith]

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]

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

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 "Planningublic 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_(for_this_wiki)>

 

[CBFalconer]

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

Jordan Abel wrote
(in article <[email protected]>):

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

 

[Jordan Abel]

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]

 

[Al Balmer]

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.

 

[Jordan Abel]

On Mon, 23 Jan 2006 22:14:57 GMT, Randy Howard

Jordan Abel wrote
(in article <[email protected]>):

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

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

vi could use ctags 20 years ago.

 

[Chris Smith]

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]

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

 

[Michael Mair]

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

 

[CBFalconer]

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

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]

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]

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

 

[Ian Collins]

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?

 

[Richard Bos]

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]

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

You learn to read.

Richard

 

[Al Balmer]

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?