GNU bug report logs - #2203
C Mode: C-M-a fails at BOD re_comp, src/regex.c L6534

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2203 in the body.
You can then email your comments to 2203 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: C Mode:  C-M-a fails at BOD re_comp, src/regex.c L6534
Date: Thu, 5 Feb 2009 11:36:45 +0000

In .../src/regex.c put point at BOL6534, "char *" here:

}
WEAK_ALIAS (__re_compile_pattern, re_compile_pattern)
^L
/* Entry points compatible with 4.2 BSD regex library.  We don't define
   them unless specifically requested.  */

#if defined _REGEX_RE_COMP || defined _LIBC

/* BSD has one and only one pattern buffer.  */
static struct re_pattern_buffer re_comp_buf;

char *                                          <=================================
# ifdef _LIBC
/* Make these definitions weak in libc, so POSIX programs can redefine
   these names if they don't use our functions, and still use
   regcomp/regexec below without link errors.  */
weak_function
# endif
re_comp (s)
    const char *s;
{


Do C-M-a.  Point doesn't move.

Preliminary investigation:  With point on the 'h' of "char *",
(c-beginning-of-decl-1 nil) should move point one character backwards.
Instead, it moves to BOL "WEAK_ALIAS".

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #10 received at 2203 <at> debbugs.gnu.org (full text, mbox):

From: Alan J Third <alan <at> idiocy.org>
To: 2203 <at> debbugs.gnu.org
Cc: Alan Mackenzie <acm <at> muc.de>
Subject: Re: bug#2203: C Mode:  C-M-a fails at BOD re_comp, src/regex.c L6534
Date: Fri, 15 Jan 2016 20:40:31 +0000

Alan Mackenzie <acm <at> muc.de> writes:

> In .../src/regex.c put point at BOL6534, "char *" here:
>
> }
> WEAK_ALIAS (__re_compile_pattern, re_compile_pattern)
> ^L
> /* Entry points compatible with 4.2 BSD regex library.  We don't define
>    them unless specifically requested.  */
>
> #if defined _REGEX_RE_COMP || defined _LIBC
>
> /* BSD has one and only one pattern buffer.  */
> static struct re_pattern_buffer re_comp_buf;
>
> char *                                          <=================================
> # ifdef _LIBC
> /* Make these definitions weak in libc, so POSIX programs can redefine
>    these names if they don't use our functions, and still use
>    regcomp/regexec below without link errors.  */
> weak_function
> # endif
> re_comp (s)
>     const char *s;
> {
>
>
> Do C-M-a.  Point doesn't move.
>
> Preliminary investigation:  With point on the 'h' of "char *",
> (c-beginning-of-decl-1 nil) should move point one character backwards.
> Instead, it moves to BOL "WEAK_ALIAS".

I just tested this in Emacs 25 and it seems that in every case point
moves back to "WEAK_ALIAS". That is, C-M-a, c-beginning-of-defun,
behaves the same way as (c-beginning-of-decl-1 nil).

I guess that makes it more broken, if more consistent, than when the bug
was raised.

-- 
Alan Third

Message #13 received at 2203 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Alan J Third <alan <at> idiocy.org>
Cc: 2203 <at> debbugs.gnu.org
Subject: Re: bug#2203: C Mode:  C-M-a fails at BOD re_comp, src/regex.c L6534
Date: 17 Jan 2016 22:31:14 -0000

Hello, Alan.

In article <mailman.2414.1452890468.843.bug-gnu-emacs <at> gnu.org> you wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

>> In .../src/regex.c put point at BOL6534, "char *" here:
>>
>> }
>> WEAK_ALIAS (__re_compile_pattern, re_compile_pattern)
>> ^L
>> /* Entry points compatible with 4.2 BSD regex library.  We don't define
>>    them unless specifically requested.  */
>>
>> #if defined _REGEX_RE_COMP || defined _LIBC
>>
>> /* BSD has one and only one pattern buffer.  */
>> static struct re_pattern_buffer re_comp_buf;
>>
>> char *                                          <=================================
>> # ifdef _LIBC
>> /* Make these definitions weak in libc, so POSIX programs can redefine
>>    these names if they don't use our functions, and still use
>>    regcomp/regexec below without link errors.  */
>> weak_function
>> # endif
>> re_comp (s)
>>     const char *s;
>> {
>>
>>
>> Do C-M-a.  Point doesn't move.
>>
>> Preliminary investigation:  With point on the 'h' of "char *",
>> (c-beginning-of-decl-1 nil) should move point one character backwards.
>> Instead, it moves to BOL "WEAK_ALIAS".

> I just tested this in Emacs 25 and it seems that in every case point
> moves back to "WEAK_ALIAS". That is, C-M-a, c-beginning-of-defun,
> behaves the same way as (c-beginning-of-decl-1 nil).

> I guess that makes it more broken, if more consistent, than when the bug
> was raised.

What is happening is that CC Mode is spuriously recognising WEAK_ALIAS as
an old style "K&R" declaration[*], the line

    static struct re_pattern_buffer re_comp_buf;

being a "type declaration for the parameter re_comp_buf".

I'm tightening up the detection of K&R declarations such that in each
putative type declaration of an identifier, that identifier must also
appear inside the function's arglist.

[*] A K&R declaration in C is one looking like this:

    static PyObject **
    unpack_sequence(v, argcnt, why)
        PyObject **v;
        int argcnt;
        enum why_code *why;
    {

rather than the now ubiquitous modern form:

    static PyObject **
    unpack_sequence (PyObject **v, int argcnt, enum why_comde *why)
    {
    
> Alan Third

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #18 received at 2203-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 2203-done <at> debbugs.gnu.org
Subject: Re: bug#2203: C Mode:  C-M-a fails at BOD re_comp, src/regex.c L6534
Date: 22 Jan 2016 23:06:47 -0000

Bug fixed in branch emacs-25.

In article <mailman.2414.1452890468.843.bug-gnu-emacs <at> gnu.org> you wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

>> In .../src/regex.c put point at BOL6534, "char *" here:
>>
>> }
>> WEAK_ALIAS (__re_compile_pattern, re_compile_pattern)
>> ^L
>> /* Entry points compatible with 4.2 BSD regex library.  We don't define
>>    them unless specifically requested.  */
>>
>> #if defined _REGEX_RE_COMP || defined _LIBC
>>
>> /* BSD has one and only one pattern buffer.  */
>> static struct re_pattern_buffer re_comp_buf;
>>
>> char *                                          <=================================
>> # ifdef _LIBC
>> /* Make these definitions weak in libc, so POSIX programs can redefine
>>    these names if they don't use our functions, and still use
>>    regcomp/regexec below without link errors.  */
>> weak_function
>> # endif
>> re_comp (s)
>>     const char *s;
>> {
>>
>>
>> Do C-M-a.  Point doesn't move.
>>
>> Preliminary investigation:  With point on the 'h' of "char *",
>> (c-beginning-of-decl-1 nil) should move point one character backwards.
>> Instead, it moves to BOL "WEAK_ALIAS".

> I just tested this in Emacs 25 and it seems that in every case point
> moves back to "WEAK_ALIAS". That is, C-M-a, c-beginning-of-defun,
> behaves the same way as (c-beginning-of-decl-1 nil).

> I guess that makes it more broken, if more consistent, than when the bug
> was raised.

> -- 
> Alan Third

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.