[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: - c-end-of-defun - !
From: |
A Soare |
Subject: |
Re: - c-end-of-defun - ! |
Date: |
Wed, 18 Apr 2007 21:36:22 +0200 (CEST) |
Shell I do the patch tomorrow? Or it has already been done?
A Soare.
> Message du 18/04/07 à 20h38
> De : "Alan Mackenzie" <address@hidden>
> A : "A Soare" <address@hidden>, "Andreas Schwab" <address@hidden>
> Copie à : "Chong Yidong" <address@hidden>, address@hidden, address@hidden
> Objet : Re: - c-end-of-defun - !
>
> 'evening, Alin and Andreas!
>
> Thank you both very much for reporting this bug! (Andreas: the bug you
> reported 2 hours after Alin is the same bug.)
>
> On Wed, Apr 18, 2007 at 03:17:00PM +0200, A Soare wrote:
> >
> > int
> > function (void)
> > {
> > int b;
> >
> > }
>
> > struct ONE function (void)
> > {
> > int a;
> >
> > }
>
> > struct
> > TWO function (void)
> > {
> > int a;
> >
> > }
>
> >
> > Here are 3 valid functions written in C.
> > Copy them into a buffer in C-MODE, and eval (end-of defun) in the first one
> > and in the second.
>
> > In the second case => FAIL.
>
> > That is because of this code in c-end-of-defun:
> >
> > ;; Do we need to move forward from the brace to the semicolon?
> > (when (eq arg 0)
> > (if (c-in-function-trailer-p) ; after "}" of struct/enum, etc.
> > (c-syntactic-re-search-forward ";"))
>
> > (c-in-function-trailer-p) in our case MUST return NULL. Not the (point).
>
> This is indeed the case.
>
> > Is really need to call (c-syntactic-re-search-forward ";") here?
>
> Yes. c-end-of-defun is being fooled by the "struct" in the functions'
> return types into thinking the function is actually a struct declaration
> like this:
>
> struct foo {
> int bar ;
> int baz ;
> } blorg ;
>
> A struct also counts as a defun, and it ends at the first semicolon
> following the brace (as contrasted with a function, which ends at the
> brace). This is what the (c-syntactic-re-search-forward ";") is for.
>
> The solution is to analyse the defuns' headers more thoroughly. It
> shouldn't be too hard, and shouldn't take too long.
>
> > Alin Soare.
>
> --
> Alan Mackenzie (Ittersbach, Germany)
>
>