Re: [Nano-devel] Bracket issue

[David Lawrence Ramsey]

Nick Warne wrote:

<snip>

>No, what I meant was could you safely presume the function { } have
>whitespace either side of it... i.e.
>
>  void* (foo) { #1
>    blah
>    blah
>    ignore this '{'
>    or this /}
>    but not this ' } '  // will still give a false positive here...
>  } #2
>
>I would expect a function brace et al to be separated by white either
>side of it.  It is bad to do this:
>
>void* (foo){
>
>or this
>
>}else{       should be --->  } else {
>
>if you get my drift.

Got it.  Sorry for any misunderstanding (as well as the delay in
answering this; I've been busy again).

>It cannot be worse than just checking all braces?

I'd agree with you that it's good practice to put whitespace between
brackets in most cases, but there's no guarantee of that everywhere, and
if it's changed, there'll probably be complaints from people who don't
do it.  (For example, some code in ffmpeg doesn't.)  Also, brackets by
themselves on a line shouldn't be ignored, as in

int main(void)
{
...
}

In any case, making the code do what you suggest will require a major
rewrite, but so will making the code handle things properly, and I'd
prefer not to have to do two major rewrites if the first is only going
to be a band-aid over the real problem, so to speak.

I've been bitten by this problem a few times myself, in any case, but
I'd like to at least get 1.3.9 out before I start ripping
do_find_bracket() apart.  (I was planning on eventually breaking its
dependency on regex searching anyway, which I think will go a long way
towards cleaning it up.)  In the meantime, maybe adding comments with
matching brackets to the problematic lines could work around the issue,
e.g.

while (1)
   {
   // parse the opening brace
   com_token = COM_Parse (&entities);
   if (!entities)
       break;
   if (com_token[0] != '{') /* } */
       gi.error ("ED_LoadFromFile: found %s when expecting {" /* } */, 
com_token);
   }