On Wed, 5 Oct 1994 thc@home.interaccess.com wrote:
> >
> >
> > I am messing around with the new class docs, and I am begining to think
> > it's to late...when I compile I get the following error:
> >
> > spell_parser.c:36: `nr' undeclared here (not in a function)
>
> * variable "nr" is not defined. You need to define
> int nr;
> (substitute int for whatever you want) at the
> begining of your function.
>
> > spell_parser.c:36: parse error before `.'
> > spell_parser.c: In function `do_cast':
> > spell_parser.c:823: parse error before `:'
> > spell_parser.c:840: parse error before `:'
> > spell_parser.c:846: parse error before `:'
> > spell_parser.c: In function `assign_spell_pointers':
> > spell_parser.c:1057: parse error at end of input
> > *** Error code 1
>
Okay, well I'll try to help you out a bit from what I've come to
learn over the years.
First and foremost, *always* fix the parse errors. If you don't
know what a parse error is...well in simple terms it means the
brackets don't match up somewhere. Examples:
if ((MAX(blah,blah) > 0) { <-- parse error - ()'s don't add up
do_stuff; I have 3 ('s and only 2 )'s
}
if (MAX(1,0) == 1) {
assert(my_opinion);
do_stuff_one;
else { <-- parse error - should be:
assert(your_opinion); "} else {" to make {}'s match up
do_more_stuff;
}
sprintf(buf, "%s kicks you in the nuts.\n, GET_NAME(ch));
^
|
parse error - the quotes " " don't
match up right. Most of the time
gcc will give you a hint as to where
it thinks the 'runaway' string is at.
(IE - line number and a message)
Parse errors are a real pain in the ass, unless you use EMACS or
even VI as an editor. EMACS will move the cursor briefly to
the matching bracket when you type a closing bracket in - ") } or ]".
In VI, you can place the cursor on any bracket, and then hit
the "%" key (shift-5). This tells VI to take you to the bracket
that currently matches up with the one your on. Hit it a second
time and your back on the bracket you started on.
Now in this case, judging by your compiler errors, and more
specifically:
spell_parser.c:1057: parse error at end of input
This tells me you forgot a "}" bracket somewhere, because the
the compiler reached the end of the file, and (simply) there are
more {'s than there are }'s to match them, and it's still expecting
more code. Whatever code you put in, has an unmatched {} pair.
Hope that helps you out.
Now, the reason you *always* fix parse errors first (okay, okay,
the reason *I* always fix them first) is that parse errors will
screw up the compiler's tables, queue, pointers, whatever.
You will get all kinds of errors like:
file:line_number:redeclaration of 'buf'
file:line_number:previous declaration here.
or
file:line_number:implicitly declared here
Variables won't match up, and you'll even get a couple of these
once in a while:
spell_parser.c:36: `nr' undeclared here (not in a function)
or
file:line_number: 'nr' not defined.
The reason is that, with the way your brackets are matching up,
some lines of code might look like they are in between functions
to the compiler, or variable declarations may look like they are
in a different function than the references to the variable.
Either way, the compiler doesn't like it. So basically it
can cause a heck of a lot more errors than are really there if you
have parse errors. Your code may be fine, except for one missing
"}" somewhere. Try this sometime - go into act.whateverfile.c,
and remove the end-of-function bracket of the first function
you find, then try compiling it, and you'll see what I mean -
tons of errors caused by one missing "}".
Hope this helps some of those newbie IMPS who I am not "flaming" =)
====================================================================
Christopher Herringshaw Networking and Special Projects Division
Medical Center Information Technology (MCIT) xxviper@med.umich.edu
University of Michigan Medical Center, B1911 CFOB
1414 Catherine Street, Ann Arbor, MI 48109-0704 (313) 747-2778
====================================================================
This archive was generated by hypermail 2b30 : 12/07/00 PST