From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Gauthier Ostervall Newsgroups: gmane.emacs.bugs Subject: bug#14133: 24.2; c functions recognition breaks on certain preprocessor macros Date: Wed, 3 Apr 2013 12:48:37 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1365008343 20697 80.91.229.3 (3 Apr 2013 16:59:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Apr 2013 16:59:03 +0000 (UTC) To: 14133@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 18:59:31 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UNR23-0000Vc-29 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 18:59:31 +0200 Original-Received: from localhost ([::1]:40821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNR1e-0000L7-EH for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 12:59:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNR1Z-0000Jx-EV for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:59:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNR1W-0003Pl-M3 for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:59:01 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNR1W-0003Pg-IV for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:58:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UNR4V-0006Si-4r for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2013 13:02:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gauthier Ostervall Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2013 17:02:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 14133 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.136500851724816 (code B ref -1); Wed, 03 Apr 2013 17:02:03 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Apr 2013 17:01:57 +0000 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:73110 Archived-At: Function coloring, c-beginning-of-defun and c-end-of-defun behaves strangely if the functions contain ifdef'd code. For example: void function_one(void) { // Make the number of spaces before # vary. #if defined(DEBUG) trap(); #endif // DEBUG } void function_two(void) { // doing nothing } The number of spaces that precede the macros seem to influence the strange behavior. At first I thought that the c-*-of-defun functions worked if both C-macros were aligned, but it is not always the case. It is quite easy to see if the current state is working or not: the identifier 'function_two' is not colored correctly when the function recognition fails. There seems also to be differences depending on the form of the macro: #if defined(DEBUG) #if defined DEBUG #ifdef DEBUG The cases showing the fault depend on the previous states, the file content alone is not enough to guarantee seeing the fault. Examples of code that causes the fault (only function_one is shown for readability, see above for function_two): --- 1 --- 1.a. // -- OK void function_one(void) { // Make the number of spaces before # vary. #if defined DEBUG trap(); #endif // DEBUG } 1.b. Add one space before #if -> Fail 1.c. Add one more space before #if -> OK 1.d. Delete the space added in 1.c. -> still OK (although same content as in 1.b.). --- 2 --- 2.a. // --- OK void function_one(void) { // Make the number of spaces before # vary. #if defined DEBUG trap(); #endif // DEBUG } 2.b. Add one space before #if -> OK (unlike case 1) 2.c. Add one more space before #if -> Fail 2.d. Delete the space added in 2.c. -> still Fail (although same content as in 2.b.). 2.e. Remove the last space before #if -> OK --- 3 --- 3.a. // --- OK void function_one(void) { // Make the number of spaces before # vary. #if defined DEBUG trap(); #endif // DEBUG } 3.b. Add four spaces before #if -> Fail 3.c. Add one space before #endif -> Fail 3.d. Add one space before #endif -> OK 3.e. Delete one space before #endif -> OK (although same content as 3.c) As far as I can see, the behavior of #ifdef is the same as that of #if defined without parens. The behavior of #if defined with parens differs, though. IIRC, all preprocessor macros should be considered as blank lines when it comes to function recognition?