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

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

bug#23313: 25.0.92; CC Mode not recognizing function declarations that r


From: Alan Mackenzie
Subject: bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type
Date: Mon, 25 Apr 2016 11:14:34 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Mohammed.

On Sat, Apr 23, 2016 at 10:17:13PM +0530, Mohammed Sadik wrote:
> On 4/23/16, Alan Mackenzie <address@hidden> wrote:

> > OK, I've written a trial patch along these lines.  Could you try it out,
> > please, and let me know whether it works OK, or still has some faults.

>  <snip>

> The patch was not applying to my Emacs 25.0.93 source. patched by hand.
>  And I tried your patch. It was working right, with some minor glitches:

Sorry about the bad patch.  I made it to apply to the emacs-25 branch.
Obviously, I made a mistake somewhere.

> *  The right face is applied only after the statement is made complete
> with a ';'

> GtkWidget
> my_app_window (|)

> The above code is interpreted as a function (without ';') but the one
> below doesn't:

> GtkWidget *
> my_app_window (|)

> There might be issues guessing the right way. That is, if the * is for
> representing a
> pointer or mathematical multiplication, ....

That's precisely the issue.  I've tried removing the condition for the
semicolon.  Unfortunately, CC Mode then misfontifies both of the
following (from a CC Mode test file) as declarations:

    t3  *id  (NULL) + 1;
    t3  (id) (NULL) + 1;        

> .... but the following is also not interpreted right (when without
> ';'):

> GtkWidget **
> my_app_window (|)

> As ** is clearly a pointer to pointer,  cc-mode shall be able to guess
> very early.

It's not actually that clear.  The second star could be accessing the
pointer returned by calling my_app_window.  ;-)

> I'm not an expert, though the following interpretation might be good:
> 1. GtkWidget |
>    'GtkWidget' may be an identifier, data type, etc.

> 2. GtkWidget *|
>    'GtkWidget' _may_ be a data type (as '*' _may_ not be present to represent
>    multiplication as its is not allowed as lvalue).

> 3. GtkWidget **|
>    'GtkWidget' is surely a data type. (not implemented now in c-mode)

See above.

> 4. GtkWidget * my_app_window|
>    (2) and my_app_window may be an identifier.

> 5. GtkWidget * my_app_window (|
>    'GtkWidget' may be a data type and 'my_app_window' may be a function.

> 6.  GtkWidget * my_app_window (int|
>     This is not a function call, as 'int' is a data type. So probably
>     a function definition/declaration).

I'd agree with you on number 6.  Trouble is, most types used are user
defined, and not easy to distinguish from variable names.

I've thought long and hard about this needing a semicolon to fontify an
"ambiguous" declaration.  In the end, I've decided that this is a lesser
evil than leaving valid (if unusual and not very useful) function
invocations wrongly fontified as declarations.  There is also something
positive in reminding the user to type that final semicolon, even if
it's not consistent.  So, sorry about this.

So I think this bug is now fixed.  Assuming I don't hear from you about
any more problems, I'll commit the patch to the master branch, and mark
the bug report as fixed.

Thanks for all the trouble you've taken over it.

> Regards
>     Mohammed Sadik

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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