Asp Forum - compiler switch to indicate "end of function"?

David Mathog

5/10/2011 4:00:00 PM

Sometimes when editing a source file a close brace is accidentally
deleted, and when that happens, at least with gcc, the error messages
are not very helpful in locating the error. Error messages are
generated from code below it, although not necessarily very near to
it, going on sometimes to the end of the file, thousands of lines
later. These errors can propagate through dozens of functions. Which
makes me wonder if there is something in the standard like:

#endfunction

to tell the compiler that if there is anything dangling in a function
at that point to throw an error there, and to start over cleanly below
the compiler directive. So that when

void somefunc(void){
/* bunch of stuff, including one too few "}" */
}
#endfunction

it will be clear from the messages that the problem is in somefunc().
In some instances I have had to emulate this by cutting off large
chunks of a file with

#ifdef NOTDEFINED

until the code is small enough to find the error.

Thanks,

David Mathog

38 Answers

Tom St Denis

5/10/2011 5:08:00 PM

On May 10, 12:00 pm, David Mathog <dmat...@gmail.com> wrote:
> Sometimes when editing a source file a close brace is accidentally
> deleted, and when that happens, at least with gcc, the error messages
> are not very helpful in locating the error. Error messages are
> generated from code below it, although not necessarily very near to
> it, going on sometimes to the end of the file, thousands of lines
> later. These errors can propagate through dozens of functions. Which
> makes me wonder if there is something in the standard like:
>
> #endfunction
>
> to tell the compiler that if there is anything dangling in a function
> at that point to throw an error there, and to start over cleanly below
> the compiler directive. So that when
>
> void somefunc(void){
> /* bunch of stuff, including one too few "}" */}
>
> #endfunction

This problem can be mitigated a bit by factoring your code so you
don't put many functions in a single file [or compilation unit]. I
usually hit the analogue of this problem when missing a ';' from a
header file, the compiler [gcc] goes off on a rant about invalid asm
declarations or whatever. Though with experience I know exactly what
went wrong.

Also, compile early and often. It helps weed out these annoying
configuration/layout/etc errors.

Tom

Ben Pfaff

5/10/2011 5:30:00 PM

Keith Thompson

5/10/2011 5:38:00 PM

David Mathog <dmathog@gmail.com> writes:
> Sometimes when editing a source file a close brace is accidentally
> deleted, and when that happens, at least with gcc, the error messages
> are not very helpful in locating the error. Error messages are
> generated from code below it, although not necessarily very near to
> it, going on sometimes to the end of the file, thousands of lines
> later. These errors can propagate through dozens of functions. Which
> makes me wonder if there is something in the standard like:
>
> #endfunction
>
> to tell the compiler that if there is anything dangling in a function
> at that point to throw an error there, and to start over cleanly below
> the compiler directive. So that when
>
> void somefunc(void){
> /* bunch of stuff, including one too few "}" */
> }
> #endfunction
>
> it will be clear from the messages that the problem is in somefunc().
> In some instances I have had to emulate this by cutting off large
> chunks of a file with
>
> #ifdef NOTDEFINED
>
> until the code is small enough to find the error.

There's nothing like that in the standard, and I've never heard of
any compiler providing it as an extension.

When you get a syntax error, it's often best to ignore everything
but the first error message. Anything after that tends to be the
result of the compiler's attempt to recover and continue parsing,
and C's grammar is such that the attempt often fails.

If I suspect I've left out a closing brace, I'll go to the line in
the source file corresponding to the first error message, then go
from there to the opening '{' of the enclosing function and try
to find the matching '}'. (In vi/vim, '%' jumps to the matching
brace; other editors should have something similar). If there is no
matching '}', or if there is but it's not at the right indentation,
I start looking at enclosed brace pairs.

Running the source file through a formatter ("indent -kr", for
example, or a "reformat source" command if you use a GUI IDE)
might also be helpful in narrowing down the problem.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Kleuskes & Moos

5/10/2011 8:34:00 PM

On May 10, 6:00 pm, David Mathog <dmat...@gmail.com> wrote:
> Sometimes when editing a source file a close brace is accidentally
> deleted, and when that happens, at least with gcc, the error messages
> are not very helpful in locating the error. Error messages are
> generated from code below it, although not necessarily very near to
> it, going on sometimes to the end of the file, thousands of lines
> later. These errors can propagate through dozens of functions. Which
> makes me wonder if there is something in the standard like:
>
> #endfunction
>
> to tell the compiler that if there is anything dangling in a function
> at that point to throw an error there, and to start over cleanly below
> the compiler directive. So that when
>
> void somefunc(void){
> /* bunch of stuff, including one too few "}" */}
>
> #endfunction
>
> it will be clear from the messages that the problem is in somefunc().
> In some instances I have had to emulate this by cutting off large
> chunks of a file with
>
> #ifdef NOTDEFINED
>
> until the code is small enough to find the error.
>
> Thanks,
>
> David Mathog

Ok. I;m sure i'll get the same flak as last time for supplying some
good advice, but your coding style is the main culprit, i think.
Instead of acknowledging the braces as the important structural
elements they are, your treat them like bums and try to hide them, as
if hey don't really matter.

if instead of

void somefunc(void){
/* bunch of stuff, including one too few "}" */}

you write

void somefunc(void)
{
#if 0
{
bunch of stuff,
{
/* Some comment */
including one too few "{" and "}"
}
/* some more comment */
}
#endif
}

I'm sure you'll make a lot less errors. Braces are so important in
determining the structure of a C program, they deserve their own line.
And don't try to tell me that whitespace costs money, since that's
only valid on paper.

Seebs

5/10/2011 9:23:00 PM

On 2011-05-10, Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> {
> /* Some comment */
> including one too few "{" and "}"
> }

> I'm sure you'll make a lot less errors. Braces are so important in
> determining the structure of a C program, they deserve their own line.

This is not 1TBS. Therefore it's wrong.

Here's the thing: Brace styles are all viable. Any of them will work.
But it's VERY useful to have everyone use the same style.

There is no way to pick a standard except by appeal to authority. Therefore,
use the brace style from K&R. That's the closest we'll ever have to a
proper authority.

> And don't try to tell me that whitespace costs money, since that's
> only valid on paper.

It's not money, it's visual real estate. I can only see so many lines
at a time. Seeing a few more lines of code at a time is a pretty noticeable
payoff.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

David Mathog

5/10/2011 10:54:00 PM

On May 10, 10:30 am, Ben Pfaff <b...@cs.stanford.edu> wrote:
> David Mathog <dmat...@gmail.com> writes:
> > Sometimes when editing a source file a close brace is accidentally
> > deleted, and when that happens, at least with gcc, the error messages
> > are not very helpful in locating the error. Error messages are
> > generated from code below it, although not necessarily very near to
> > it, going on sometimes to the end of the file, thousands of lines
> > later.
>
> If you have an auto-indenting editor, just tell it to re-indent
> the whole file and look for the spot where the left margin shifts
> rightward a tab stop. It's usually obvious.
>
> If you are using a version-control system (and if not, why not?),
> look at the diff against the last checked-in version. If it's
> indeed a file with thousands of lines, probably the actual
> changes are much smaller and you may be able to easily pick out
> where you deleted a closing brace.
>
> Try using another compiler or C parser. GCC is excessively
> forgiving because it allows nested function definitions; other
> compilers will give an error at the first nested function
> definition, since they don't have that extension.
> --
> Ben Pfaffhttp://be...

David Mathog

5/10/2011 10:56:00 PM

On May 10, 10:30 am, Ben Pfaff <b...@cs.stanford.edu> wrote:

> Try using another compiler or C parser. GCC is excessively
> forgiving because it allows nested function definitions;

Ah, so that's why it goes on so long. So I can get a similar result
with:

-fno-nested-functions

Might as well add that, as I don't think I have ever intentionally
used a nested function.

Thanks,

David Mathog

Kleuskes & Moos

5/10/2011 11:01:00 PM

On May 10, 11:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-05-10, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
>
> > {
> > /* Some comment */
> > including one too few "{" and "}"
> > }
> > I'm sure you'll make a lot less errors. Braces are so important in
> > determining the structure of a C program, they deserve their own line.
>
> This is not 1TBS. Therefore it's wrong.

:).

> Here's the thing: Brace styles are all viable. Any of them will work.
> But it's VERY useful to have everyone use the same style.

True. It's also very handy to be able to easily spot where you went
wrong, especially with important language elements such as braces. If
you think otherwise, feel free to do it otherwise.

Many program-editors offer nice colorful indicators to match '{' with
'}' and '(' with ')'. I suggest you turn that on, too.

> There is no way to pick a standard except by appeal to authority.

I'm merely offering a colleage some advice that worked quite good for
me. All the places i worked that actually HAD a formalized coding
style (the best half of my employers, and you don't wanna know about
the worst ones), demanded separate lines for braces. But that's just
me and those silly employers of mine.

> Therefore, use the brace style from K&R. That's the closest we'll ever
> have to a proper authority.

Arguments from authoroty are never quite satisfying, and a debate is
quite useless (and endless), so i'm not getting into that. In my
current firm, where I am the sole and undisputed authority on these
matters, K&R can go screw themselves in this respect, however much i
admire them for their work.

What you do in your code, is your business.

> > And don't try to tell me that whitespace costs money, since that's
> > only valid on paper.
>
> It's not money, it's visual real estate. I can only see so many lines
> at a time. Seeing a few more lines of code at a time is a pretty noticeable
> payoff.

After years of contemplating the matter, i arrived at the conclusion
that it is unwise to want as much information as possible on your
screen. What you want is the _right_ information, and to be able to
spot it quickly.

Datesfat Chicks

5/10/2011 11:32:00 PM

On Tue, 10 May 2011 10:30:18 -0700, Ben Pfaff <blp@cs.stanford.edu>
wrote:

>David Mathog <dmathog@gmail.com> writes:
>
>> Sometimes when editing a source file a close brace is accidentally
>> deleted, and when that happens, at least with gcc, the error messages
>> are not very helpful in locating the error. Error messages are
>> generated from code below it, although not necessarily very near to
>> it, going on sometimes to the end of the file, thousands of lines
>> later.
>
>If you have an auto-indenting editor, just tell it to re-indent
>the whole file and look for the spot where the left margin shifts
>rightward a tab stop. It's usually obvious.
>
>If you are using a version-control system (and if not, why not?),
>look at the diff against the last checked-in version. If it's
>indeed a file with thousands of lines, probably the actual
>changes are much smaller and you may be able to easily pick out
>where you deleted a closing brace.

To the OP: I use "cvs" with "ViewVC". There is a lot of truth to
Ben's assertion that a version control system helps. You might also
try "svn".

Shamefully, I once had to go a step further (but not with gcc).
Unknown to me, I had typed a control sequence and my favorite text
editor put a non-printing invisible character in my source file.

I got so frustrated that I did a "diff" (as Ben suggested), which
didn't seem to show a problem.

So I deleted my "sandbox" copy, checked out the last revision again,
then manually reapplied the changes shown by the diff one at a time.

>Try using another compiler or C parser. GCC is excessively
>forgiving because it allows nested function definitions; other
>compilers will give an error at the first nested function
>definition, since they don't have that extension.

Whoa! I learned something new.

I have not seen nested functions since Pascal. I did not know that
any C compiler implemented those. Interesting.

In case you're young enough not to remember Pascal:

http://en.wikipedia.org/wi...(programming_language)

http://en.wikipedia.org/wiki/Tu...

http://en.wikipedia.org/wiki/Neste...

Those links bring back memories ...

DFC

Ian Collins

5/11/2011 12:32:00 AM

On 05/11/11 09:22 AM, Seebs wrote:
> On 2011-05-10, Kleuskes& Moos<kleuske@xs4all.nl> wrote:
>
>> And don't try to tell me that whitespace costs money, since that's
>> only valid on paper.
>
> It's not money, it's visual real estate. I can only see so many lines
> at a time. Seeing a few more lines of code at a time is a pretty noticeable
> payoff.

I can see 112 lines with the large font I use, but I doubt I can parse
them all at once. I add whitespace and braces to break the code up into
visually distinct blocks. When I could only see a fraction the number
of lines (despite better eyesight!), I wrote denser code.

Displays have improved beyond recognition in the last 20 years and
coding styles should adapt to suit.

--
Ian Collins

comp.lang.c

compiler switch to indicate "end of function"?

David Mathog

Tom St Denis

Ben Pfaff

Keith Thompson

Kleuskes & Moos

Seebs

David Mathog

David Mathog

Kleuskes & Moos

Datesfat Chicks

Ian Collins

x Login to ForumsZone