From unknown Wed Jun 18 23:04:48 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#14133 <14133@debbugs.gnu.org> To: bug#14133 <14133@debbugs.gnu.org> Subject: Status: 24.2; c functions recognition breaks on certain preprocessor macros Reply-To: bug#14133 <14133@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:04:48 +0000 retitle 14133 24.2; c functions recognition breaks on certain preprocessor = macros reassign 14133 emacs,cc-mode submitter 14133 Gauthier Ostervall severity 14133 normal thanks From unknown Wed Jun 18 23:04:48 2025 Received: (at submit) by debbugs.gnu.org; 3 Apr 2013 17:01:57 +0000 From: Gauthier Ostervall Subject: 24.2; c functions recognition breaks on certain preprocessor macros X-Debbugs-Envelope-To: submit Message-Id: To: bug-gnu-emacs@gnu.org Date: Wed, 3 Apr 2013 12:48:37 +0200 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 09 02:37:28 2013 Received: (at 14133) by debbugs.gnu.org; 9 Apr 2013 06:37:28 +0000 Received: from localhost ([127.0.0.1]:41076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPSBK-00019E-Eq for submit@debbugs.gnu.org; Tue, 09 Apr 2013 02:37:28 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:44028) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPSBH-000195-Um for 14133@debbugs.gnu.org; Tue, 09 Apr 2013 02:37:25 -0400 Received: by mail-wg0-f52.google.com with SMTP id n12so6611763wgh.19 for <14133@debbugs.gnu.org>; Mon, 08 Apr 2013 23:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type:x-gm-message-state; bh=d0liUsSeCisiIMuubqTdeMk34FGMcQGqcKrTPBaa938=; b=MyjBX87BNiRvkW2LZGkStWyXHgtK0Dm+ah574AeggIrf4m5A8s0FjdVg108d+ki78x vHYrRov99QfCTJirggvCWm7EAuRkySzSJS7NfsDAbVq6tGC5nAUFkdMVfIk5GPypzK6+ 9mc3UKVp2DEPOP4/SzGe73HjGd33mfHQQOl/W2eN6NZTG5pJZz6Q/VqkFCMSkF5vGZPd yk2H+/Utm+lHPopxTQweZ3llasD+9ccUtIDJqeTjhCvr8Di+xvmcxEXmOy/W07zbQnlC DaZNIW/md58Ub/bxFr90avEMdVfGl2s9pHOJ3aYWHM8bvlrXKq3DkMCAubyd/O2K3dkQ bWZg== X-Received: by 10.180.13.34 with SMTP id e2mr17409565wic.29.1365489226861; Mon, 08 Apr 2013 23:33:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.125.15 with HTTP; Mon, 8 Apr 2013 23:33:26 -0700 (PDT) X-Originating-IP: [212.247.43.194] In-Reply-To: References: From: =?ISO-8859-1?Q?Gauthier_=D6stervall?= Date: Tue, 9 Apr 2013 08:33:26 +0200 Message-ID: Subject: Re: bug#14133: 24.2; c functions recognition breaks on certain preprocessor macros To: 14133@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm4lofyaAOpPAhzvppOHpLZ+WMeptURWnWLWy9weRax/uY1edE/l1jSihboAvMium8LBjtr X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 14133 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Wed, Apr 3, 2013 at 12:48 PM, Gauthier Ostervall wrote: > Function coloring, c-beginning-of-defun and c-end-of-defun behaves > strangely if the functions contain ifdef'd code. > > bug#14133: 24.2; Faulty behavior also verified on 24.3.1 Working as expected on 23.4.1 All version installed from the zip files at http://ftp.gnu.org/gnu/emacs/windows/ , on Windows 7. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 09 17:10:22 2013 Received: (at 14133) by debbugs.gnu.org; 9 Apr 2013 21:10:22 +0000 Received: from localhost ([127.0.0.1]:42431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPfo6-00085B-B5 for submit@debbugs.gnu.org; Tue, 09 Apr 2013 17:10:22 -0400 Received: from colin.muc.de ([193.149.48.1]:35693 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPfo3-000853-I9 for 14133@debbugs.gnu.org; Tue, 09 Apr 2013 17:10:21 -0400 Received: (qmail 28524 invoked by uid 3782); 9 Apr 2013 21:06:38 -0000 Received: from acm.muc.de (pD9519A9F.dip.t-dialin.net [217.81.154.159]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 09 Apr 2013 23:06:37 +0200 Received: (qmail 3665 invoked by uid 1000); 9 Apr 2013 21:06:21 -0000 Date: Tue, 9 Apr 2013 21:06:21 +0000 To: 14133@debbugs.gnu.org Subject: Re: 24.2; c functions recognition breaks on certain preprocessor macros Message-ID: <20130409210621.GA3571@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 14133 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) Hi, Gauthier. > Function coloring, c-beginning-of-defun and c-end-of-defun behaves > strangely if the functions contain ifdef'd code. More precisely, doing C-M-a from function_two goes to the beginning of function_one. I couldn't see any fault with the font locking, though. > 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. Actually, it is the prescence of spaces before the # which are triggering the bug. > 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. I didn't see this. Would you please try the patch below and let me know how much it fixes and how much is still not working. After applying the patch, you MUST byte-compile cc-langs.el, cc-engine.el and cc-mode.el, for it to work. (Let me know if you have any trouble doing this.) Thanks for taking the trouble to report the bug. Here's the patch: === modified file 'lisp/progmodes/cc-langs.el' *** lisp/progmodes/cc-langs.el 2013-03-05 17:13:01 +0000 --- lisp/progmodes/cc-langs.el 2013-04-09 20:36:25 +0000 *************** *** 812,819 **** (c-lang-defconst c-anchored-cpp-prefix "Regexp matching the prefix of a cpp directive anchored to BOL, in the languages that have a macro preprocessor." ! t (if (c-lang-const c-opt-cpp-prefix) ! (concat "^" (c-lang-const c-opt-cpp-prefix)))) (c-lang-defvar c-anchored-cpp-prefix (c-lang-const c-anchored-cpp-prefix)) (c-lang-defconst c-opt-cpp-start --- 812,819 ---- (c-lang-defconst c-anchored-cpp-prefix "Regexp matching the prefix of a cpp directive anchored to BOL, in the languages that have a macro preprocessor." ! t "^\\s *\\(#\\)\\s *" ! (java awk) nil) (c-lang-defvar c-anchored-cpp-prefix (c-lang-const c-anchored-cpp-prefix)) (c-lang-defconst c-opt-cpp-start === modified file 'lisp/progmodes/cc-mode.el' *** lisp/progmodes/cc-mode.el 2013-01-02 16:13:04 +0000 --- lisp/progmodes/cc-mode.el 2013-04-09 20:39:18 +0000 *************** *** 936,942 **** ;; Add needed properties to each CPP construct in the region. (goto-char c-new-BEG) ! (let ((pps-position c-new-BEG) pps-state mbeg) (while (and (< (point) c-new-END) (search-forward-regexp c-anchored-cpp-prefix c-new-END t)) ;; If we've found a "#" inside a string/comment, ignore it. --- 936,943 ---- ;; Add needed properties to each CPP construct in the region. (goto-char c-new-BEG) ! (skip-chars-backward " \t") ! (let ((pps-position (point)) pps-state mbeg) (while (and (< (point) c-new-END) (search-forward-regexp c-anchored-cpp-prefix c-new-END t)) ;; If we've found a "#" inside a string/comment, ignore it. *************** *** 945,958 **** pps-position (point)) (unless (or (nth 3 pps-state) ; in a string? (nth 4 pps-state)) ; in a comment? ! (goto-char (match-beginning 0)) (setq mbeg (point)) (if (> (c-syntactic-end-of-macro) mbeg) (progn (c-neutralize-CPP-line mbeg (point)) ! (c-set-cpp-delimiters mbeg (point)) ! ;(setq pps-position (point)) ! ) (forward-line)) ; no infinite loop with, e.g., "#//" ))))) --- 946,957 ---- pps-position (point)) (unless (or (nth 3 pps-state) ; in a string? (nth 4 pps-state)) ; in a comment? ! (goto-char (match-beginning 1)) (setq mbeg (point)) (if (> (c-syntactic-end-of-macro) mbeg) (progn (c-neutralize-CPP-line mbeg (point)) ! (c-set-cpp-delimiters mbeg (point))) (forward-line)) ; no infinite loop with, e.g., "#//" ))))) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 10 07:53:22 2013 Received: (at 14133) by debbugs.gnu.org; 10 Apr 2013 11:53:22 +0000 Received: from localhost ([127.0.0.1]:43231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPtab-0007Sy-Lu for submit@debbugs.gnu.org; Wed, 10 Apr 2013 07:53:22 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:50951) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPtaZ-0007SZ-HL for 14133@debbugs.gnu.org; Wed, 10 Apr 2013 07:53:20 -0400 Received: by mail-wi0-f173.google.com with SMTP id ez12so4704470wid.0 for <14133@debbugs.gnu.org>; Wed, 10 Apr 2013 04:49:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=g3+ePjQJiLpI5fOqavE2CY2hmolwYor3mISWe3XMd3o=; b=PFWWuuo0XENJwER8MbrDlf0MnpR6cx6b5TFZn0rW1SJ51e+geC1BT7ILEjxrhNuxNh C4m45J/NtWWcXrjMV5ltg7zwwkktJvaK7+WnuRo8SycA+5poXh7stGVYphZ5bgUTILFX lFPm5NEbZf4hTc4MWBZ36+EjCboODcpXrP2hbiMvpM1opOn9/znJW6zeKVbONR2e9GOj Z2u/AIN6jTSzicPSJsA9t+B6TnnF/uN/QnwgXNJONNcWzETqgqD3n/ewUwaVF7cpZf68 FaaHXyyOJf70tHsqyIVmvoc9FV7UHjcUsLqFuQvpdLn3wZIooC4KESMWyBoTtkFaWe3c ZiJw== X-Received: by 10.180.206.205 with SMTP id lq13mr2121843wic.21.1365594575645; Wed, 10 Apr 2013 04:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.19.74 with HTTP; Wed, 10 Apr 2013 04:49:15 -0700 (PDT) X-Originating-IP: [212.247.43.194] In-Reply-To: <20130409210621.GA3571@acm.acm> References: <20130409210621.GA3571@acm.acm> From: =?ISO-8859-1?Q?Gauthier_=D6stervall?= Date: Wed, 10 Apr 2013 13:49:15 +0200 Message-ID: Subject: Re: bug#14133: 24.2; c functions recognition breaks on certain preprocessor macros To: Alan Mackenzie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkliHsMWw/v5HNR/DNsf2BU9eZrciAG6x2YA/z04j0Gs4QJmAn//f4TFFjW0o1X2Qs5Oz3Z X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 14133 Cc: 14133 <14133@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Tue, Apr 9, 2013 at 11:06 PM, Alan Mackenzie wrote: > Would you please try the patch below and let me know > how much it fixes and how much is still not working. After applying the > patch, you MUST byte-compile cc-langs.el, cc-engine.el and cc-mode.el, > for it to work. (Let me know if you have any trouble doing this.) Your patch fixed this issue, thank you! (built in Cygwin) Now I will need to find out how to build emacs natively for win64 (or revert to version 23 and wait for your correction to be integrated). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 15 12:24:21 2013 Received: (at 14133-done) by debbugs.gnu.org; 15 Apr 2013 16:24:21 +0000 Received: from localhost ([127.0.0.1]:52592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1URmCZ-0000Mz-SU for submit@debbugs.gnu.org; Mon, 15 Apr 2013 12:24:20 -0400 Received: from colin.muc.de ([193.149.48.1]:33335 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1URmCV-0000Mk-QA for 14133-done@debbugs.gnu.org; Mon, 15 Apr 2013 12:24:17 -0400 Received: (qmail 14883 invoked by uid 3782); 15 Apr 2013 16:20:00 -0000 Received: from acm.muc.de (pD9519D8B.dip.t-dialin.net [217.81.157.139]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 15 Apr 2013 18:19:58 +0200 Received: (qmail 6412 invoked by uid 1000); 15 Apr 2013 16:19:39 -0000 Date: Mon, 15 Apr 2013 16:19:38 +0000 To: 14133-done@debbugs.gnu.org Subject: Re: bug#14133: 24.2; c functions recognition breaks on certain preprocessor macros Message-ID: <20130415161938.GA4496@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 14133-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) Bug fixed in the trunk. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 18 23:04:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 14 May 2013 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator