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

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

[Alan Mackenzie]

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).

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

[Alan J Third]

Alan Mackenzie <acm@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

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

[Alan Mackenzie]

Hello, Alan.

In article <mailman.2414.1452890468.843.bug-gnu-emacs@gnu.org> you wrote:
> Alan Mackenzie <acm@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).

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

[Alan Mackenzie]

Bug fixed in branch emacs-25.

In article <mailman.2414.1452890468.843.bug-gnu-emacs@gnu.org> you wrote:
> Alan Mackenzie <acm@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).