emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C indentation error.


From: Alan Mackenzie
Subject: Re: C indentation error.
Date: Fri, 31 Mar 2006 10:35:37 +0000 (GMT)

Cc: address@hidden, address@hidden,
    address@hidden
To: Michael Cadilhac <address@hidden>
From: Richard Stallman <address@hidden>

Hi, Michael, Richard!

First, a big apology for not getting back to you for so long.  As well as
all the things in Emacs, I've got serious personal stress at the moment and 
haven't been able to concentrate properly on the bug.  So, sorry.

Incidentally, Michael, your mail server has rejected my attempts to send
you mail, as follows:

Mar 31 09:58:21 acm sendmail[320]: JAA00286: to=<address@hidden>, 
delay=00:02:10, xdelay=00:00:03, mailer=esmtp, relay=smtp.lrde.epita.fr. 
[62.39.139.2], stat=Deferred: 451-193.149.49.134 is not yet authorized to 
deliver mail from <address@hidden> 
to

On Sun, 19 Mar 2006, Michael Cadilhac wrote:

>Richard Stallman <address@hidden> writes:
>
>>     >   I got an  error with some C indentation in  macro definitions in GNU
>>     >  Emacs 22.0.50.34 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
>>     >  2006-03-02.
>>     >
>>     >   Error is triggered by:
>>     >
>>     >   With emacs -Q :
>>     >   In scratch, insert the following:
>>     >
>>     > #foo :\
>>     > bar

>>     >   Toggle to c-mode, and try to indent the last line.
>>     >
>>     >   I get: Invalid search bound (wrong side of point).

Yes, this does indeed happen, and is definitely a bug.  Thank you for
reporting it.

I'm guessing that you've reduced the code down to the minimum needed to
demonstrate the bug, which is appreciated, and that you've got real code
in which this bug happened.

What is happening is that in c-forward-label, the code is trying to see
if "bar" is a label.  (It isn't, of course).  One of the things it checks
is if there is a label just before "bar".

To do this, it first moves backwards to "#foo".  Then it moves forward
over "whitespace" before calling c-forward-label recursively.  This
"whitespace" is the problem:  Since "#foo" is a preprocessor directive,
c-forward-syntactic-ws regards the entire line (including the
continuation line) as whitespace, hence point is in the wrong place .

The code here needs to be fixed to check for #things.

[ Discussion about "no-error" in c-syntactic-re-search-forward snipped. ]

>  After a little more search, I propose the following change :

>Index: lisp/progmodes/cc-engine.el
>===================================================================
>RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-engine.el,v
>retrieving revision 1.47
>diff -c -r1.47 cc-engine.el
>*** lisp/progmodes/cc-engine.el 24 Feb 2006 15:33:02 -0000      1.47
>--- lisp/progmodes/cc-engine.el 19 Mar 2006 17:59:56 -0000
>***************
>*** 5916,5922 ****
>                         ;; it shouldn't apply when we check the
>                         ;; preceding label.
>                         c-record-type-identifiers)
>!                    (c-forward-syntactic-ws)
>                     (c-forward-label nil pte start))))))))
>  
>           ;; Check that the next nonsymbol token is ":".  Allow '('
>--- 5916,5922 ----
>                         ;; it shouldn't apply when we check the
>                         ;; preceding label.
>                         c-record-type-identifiers)
>!                    (c-forward-syntactic-ws pte)
>                     (c-forward-label nil pte start))))))))
>  
>           ;; Check that the next nonsymbol token is ":".  Allow '('
>
>
>----------------------------------------------------------------------

>  Well... It fixes the bug, really, but it doesn't investigate the bug
>  as it probably should be ;  the bug _may_ be in c-forward-sws, a too
>  long function for me to work on ;-)

Your patch is a workaround rather than a fix.  I think I should be able
to fix the bug properly in the next week or two.

(Also, c-forward-sws is almost too long a function for _me_ to work on.
;-).

>  Bye !

Again, sorry for the delay in answering.

>    Michael Cadilhac, a.k.a. Micha [mika] |

-- 
Alan Mackenzie (Munich, Germany)







reply via email to

[Prev in Thread] Current Thread [Next in Thread]