`etags' bug?

`etags' bug?

[Paul Pogonyshev]

It seems that behaviour of `etags' is broken.  In GNU Go
there is a special rule for harvesting tags in pattern
files.  It looks like this:

[paul@localhost patterns]$ etags --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' aa_attackpats.db && cat TAGS


aa_attackpats.db,513
Pattern A171,2917
Pattern A282,2958
Pattern A392,3002
Pattern A4103,3037
Pattern A5114,3072
Pattern A6124,3108
Pattern A7137,3157
Pattern A8146,3210
Pattern A9155,3242
Pattern A10168,3291
Pattern A11177,3324
Pattern A12192,3382
Pattern A13209,3461
Pattern A14228,3539
Pattern A15244,3657
Pattern A16260,3761
Pattern A17278,3849
Pattern A18298,3974
Pattern A19318,4140
Pattern A20334,4259
Pattern A21350,4378
Pattern A22366,4476
Pattern A23384,4619
Pattern A24400,4744
Pattern A25414,4911


Fine, this is exactly what is needed.  Now, there are also C
files in this directory.  So, we collect tags in them too:

[paul@localhost patterns]$ etags --language none --regex '/^Pattern[ \t]+[a-zA-Z0-9]+/' aa_attackpats.db --language auto --no-regex transform.c && cat TAGS


aa_attackpats.db,227
A*A77,2939
??OO150,3230
OX163,3270
?XOXO181,3345
?XOXO187,3364
;safe_omove(*) && oplay_attack_either(*,A,B)240,3584
?XXXX249,3706
?AAAA255,3725
;!oplay_attack(*,e) && oplay_attack(*,a,C) && oplay_attack(315,4072


transform.c,179
int transformation[transformation29,1596
const int transformation2[transformation232,1682
transformation_init(61,2317
int spiral[spiral80,2691
build_spiral_order(107,3606


I believe `etags' didn't behave like this.  When I first wrote
the tag-harvesting code for patterns, it worked just fine.  Now
it generates corrupted stuff when followed by C files.

Does anyone have any idea of what's wrong?

Paul

Re: `etags' bug?

[Francesco Potorti`]

>It seems that behaviour of `etags' is broken.

Dear Paul, I cannot reproduce the behaviour you observe, neither with
the stock emacs 21.3 etags nor with the latest etags in the CVS.  It may
be a platform-dependent bug; I use a Debian system running on i686.

Before going on to debug it, make sure you are indeed using the latest
version:

$ strings ../etags|fgrep 'pot rev'
@(#) pot revision number is 17.5

and try to recompile it from scratch, to reduce the possibility that you
used some unstable library or similar problems.

If you can reproduce the bug with this version, please contact me, so we
can find a way to debug this.

Re: `etags' bug?

[Paul Pogonyshev]

> >It seems that behaviour of `etags' is broken.
>
> Dear Paul, I cannot reproduce the behaviour you observe, neither with
> the stock emacs 21.3 etags nor with the latest etags in the CVS.  It may
> be a platform-dependent bug; I use a Debian system running on i686.
>
> Before going on to debug it, make sure you are indeed using the latest
> version:
>
> $ strings ../etags|fgrep 'pot rev'
> @(#) pot revision number is 17.5
>
> and try to recompile it from scratch, to reduce the possibility that you
> used some unstable library or similar problems.
>
> If you can reproduce the bug with this version, please contact me, so we
> can find a way to debug this.

I refreshed my CVS working directory and recompiled with optimizations
turned off (`CFLAGS="-g"'.)  The behaviour didn't change.

I tried a little debugging and I don't understand how the behaviour could
be as documented.  Function main() basically looks like this:

  while ((opt = getopt_long (...)) != EOF)
    switch (opt)
      {
        /* store `--language' and `--regex' arguments in `argbuffer' */
      }

  for (; optind < argc; optind++)
    {
      /* store filenames in `argbuffer' */
    }

Now, I cannot understand how this code can distinguish between

        --language none file1 --language auto file2

and

	--language none --language auto file1 file2

_in principle_.

Yet in the man page we have

	-l language, --language=language
		Parse  the  following  files  according  to  the  given
		       ^^^^^^^^^^^^^^^^^^^^^
		language.  More than one such options may be intermixed
		with  filenames.   Use --help  to  get  a  list of  the
		available   languages   and   their  default   filename
		extensions.  The `auto' language can be used to restore
		automatic detection of language based on the file name.
		The  `none' language  may be  used to  disable language
		parsing  altogether; only  regexp matching  is  done in
		this case (see the --regex option).

Maybe I'm really missing something fundamental.

Paul

Re: `etags' bug?

[Andreas Schwab]

Paul Pogonyshev <pogonyshev@gmx.net> writes:

> I tried a little debugging and I don't understand how the behaviour could
> be as documented.  Function main() basically looks like this:
>
>   while ((opt = getopt_long (...)) != EOF)
>     switch (opt)
>       {
>         /* store `--language' and `--regex' arguments in `argbuffer' */

And file names as they are encountered between options.  Starting
optstring with '-' causes getopt to not reorder arguments:

        * If the OPTIONS argument string begins with a hyphen (`-'),
          this is treated specially.  It permits arguments that are not
          options to be returned as if they were associated with option
          character `\1'.

>       }
>
>   for (; optind < argc; optind++)
>     {
>       /* store filenames in `argbuffer' */

Only file names occuring after the last option.

So far for the theory.  Unfortunately a typo during the conversion of
LONG_OPTIONS from a preprocessing to a compile time constant has broken
this.  I've installed this patch to fix this:

2004-12-15  Andreas Schwab  <schwab@suse.de>

	* etags.c (main): Fix typo in conversion of LONG_OPTIONS from
	preprocessing to compile time constant.

--- etags.c	17 Nov 2004 10:37:38 +0100	3.43
+++ etags.c	15 Dec 2004 14:13:03 +0100	
@@ -1,5 +1,5 @@
 /* Tags file maker to go with GNU Emacs           -*- coding: latin-1 -*-
-   Copyright (C) 1984, 1987-1989, 1993-1995, 1998-2001, 2002
+   Copyright (C) 1984, 1987-1989, 1993-1995, 1998-2001, 2002, 2004
    Free Software Foundation, Inc. and Ken Arnold
 
  This file is not considered part of GNU Emacs.
@@ -1183,7 +1183,7 @@ main (argc, argv)
 #ifdef ETAGS_REGEXPS
   optstring = "-r:Rc:";
 #endif /* ETAGS_REGEXPS */
-  if (LONG_OPTIONS)
+  if (!LONG_OPTIONS)
     optstring += 1;
   optstring = concat (optstring,
 		      "Cf:Il:o:SVhH",

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `etags' bug?

[Francesco Potorti`]

>So far for the theory.  

Ok, I added a couple comments to make this clearer.

>			 Unfortunately a typo during the conversion of
>LONG_OPTIONS from a preprocessing to a compile time constant has broken
>this.  I've installed this patch to fix this:

Wow!  Thank you.  My regression test suite did not cover this case...

Paul, could you please apply Andreas' patch and, if the bug is still
there, get in touch with me?

Re: `etags' bug?

[Paul Pogonyshev]

Francesco Potorti` wrote:
> >So far for the theory.
>
> Ok, I added a couple comments to make this clearer.
>
> >			 Unfortunately a typo during the conversion of
> >LONG_OPTIONS from a preprocessing to a compile time constant has broken
> >this.  I've installed this patch to fix this:
>
> Wow!  Thank you.  My regression test suite did not cover this case...
>
> Paul, could you please apply Andreas' patch and, if the bug is still
> there, get in touch with me?

Andreas' patch fixes the problem, it now works as expected and as it did
before.  Thank you.

Paul