compiler switch to indicate "end of function"?

[David Mathog]

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

 

[Tom St Denis]

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]

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.

 

[Keith Thompson]

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.

 

[Kleuskes & Moos]

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]

{
/* 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

 

[David Mathog]

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.

 

[David Mathog]

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]

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.

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.

 

[Ian Collins]

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.

 

[Keith Thompson]

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

But that's not what he wrote. You put the closing brace at the end of a
line; he didn't.

What he actually wrote was:

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

My only quibble is that I'd put a space in front of the opening '{'.

[...]

 

[Keith Thompson]

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.

As far as I can tell, gcc has no "-fno-nested-functions" option.

You can disable nested functions using, for example, "-ansi
-pedantic" or "-std=c99 -pedantic", but that's probably not going to
change how the source code is parsed, and therefore won't help with
the cascade of errors resulting from a syntax error. More generally,
compilers that have extensions that extend the language grammar are
likely, when the extensions are disabled, to use the same grammar
but explicitly diagnose any uses of the extensions.

As I wrote elsethread, your best bet is probably just to ignore
everything after the first syntax error message, then fix the syntax
error and compile again.

 

[Keith Thompson]

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.

Personally, I don't use the K&R brace style because it's denser
than the alternatives. I use it because I find it easy to read,
and because I *like* it -- which is probably largely because it's
what I first learned. If K&R had put opening and closing braces
on their own lines, I'd probably argue in favor of that.

On the other hand, any code I write for $JOB follows the current
coding conventions. In some cases I dislike them (they vary over
time and with different languages), but the only thing worse than
a style I dislike would be a style I dislike mixed with K&R style.

(One of the styles I've had to use is:
if ( condition )
{
statement;
statement;
}
)

 

[Seebs]

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.

Oh, I totally agree that it is very handy. I just find that I don't
have any more trouble with it in 1TBS than I do in others, and indeed,
I tend to have less because it's more likely that both braces are on
screen.

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.

Agreed.

I just find that braces are not enough information to be on lines; consistent
1TBS works and does not appear to induce any mismatched-brace issues. I'd
rather see what I'm interested in than a lot of braces I'm not.

-s

 

[Ben Pfaff]

As I wrote elsethread, your best bet is probably just to ignore
everything after the first syntax error message, then fix the syntax
error and compile again.

That doesn't help with the OP's problem. Try compiling the
following with GCC, without any compiler options:

int a(void)
{
return 1;

int b(void)
{
return 2;
}

int c(void)
{
return 3;
}

The only diagnostic is this:

tmp.c: In function ‘a’:
tmp.c:13: error: expected declaration or statement at end of input

As the OP said, the location of the error is far removed from the
actual problem, a missing } at the end of a().

 

[Ben Pfaff]

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

Displays have started shrinking vertically, though. Most new
screens are 16:9 instead of the former standard 4:3. That's
fewer lines of code displayed vertically for a given amount of
screen area.

 

[Ian Collins]

Displays have started shrinking vertically, though. Most new
screens are 16:9 instead of the former standard 4:3. That's
fewer lines of code displayed vertically for a given amount of
screen area.

Below 24" yes (with a few exceptions). But decent sized (24" 16:10 and
above) still have plenty of vertical pixels.

 

[Ben Pfaff]

Below 24" yes (with a few exceptions). But decent sized (24" 16:10
and above) still have plenty of vertical pixels.

It's hard on me, though, because I prefer small laptops. My
previous 12" laptop with a 4:3 screen more easily accommodated
lots of code than my current 13.3" laptop with a 16:9 screen.

At this rate, my next laptop will have a 2:1 screen.

 

[Ian Collins]

It's hard on me, though, because I prefer small laptops. My
previous 12" laptop with a 4:3 screen more easily accommodated
lots of code than my current 13.3" laptop with a 16:9 screen.

At this rate, my next laptop will have a 2:1 screen.

It is a pain, but laptop designers tend to target DVD/BD players rather
than programmers these days. My old Dell had a 15" 1600x1200 display, a
real coder's laptop. Sadly it fell victim to our latest earthquake,
along with the fish tank that landed on it!

 

[Seebs]

Below 24" yes (with a few exceptions). But decent sized (24" 16:10 and
above) still have plenty of vertical pixels.

Even with vertical pixels, I don't do windows with lots more lines, I do
windows with up to about 30 lines and then pick larger fonts so I can
see better.

-s