Re: etags test is broken on MS-Windows

[Eli Zaretskii]

> Date: Tue, 19 May 2015 18:27:44 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> (There's also an unrelated problem with the gzip-compressed file in
> f-src, which seems to be some Windows-specific glitch; I will look
> into it separately.)

I found the reason for this: etags calls 'rewind' on a FILE stream
that was created by 'popen', which is non-portable, AFAIK.  On
Windows, that caused the initial portions of the input to be skipped
by etags, i.e. some symbols were not tagged.

There are a few comments about that in the source, like this:

  /* We rewind here, even if inf may be a pipe.  We fail if the
     length of the first line is longer than the pipe block size,
     which is unlikely. */
  rewind (inf);

These comments notwithstanding, it sounds like etags expects this to
work satisfactorily at least on GNU/Linux, and at least when "length
of the first line is not longer than the pipe block size", otherwise I
don't understand why the test suite includes gzip-compressed files
(Francesco?).

So, on the assumption that this does work on Posix hosts, at least
those that use glibc, I hacked etags to provide a Windows-specific
replacement for 'rewind' that supports this expectation, assuming the
stuff read and buffered before the call to 'rewind' is less than a
full buffer of the FILE object.  Then the Windows build no longer
misses symbols in the first part of the compressed files.

However, now I see something strange in the ETAGS.good files, which
AFAIU were produced by Paul on a Posix host.  Please look at this
excerpt from ETAGS.good_1:

f-src/entry.for,172
      LOGICAL FUNCTION PRTPKG ^?3,75
       ENTRY  SETPRT ^?194,3866
       ENTRY  MSGSEL ^?395,8478
     & intensity1(^?577,12231
       character*(*) function foo(^?579,12307
^L
f-src/entry.strange_suffix,172
      LOGICAL FUNCTION PRTPKG ^?3,75
       ENTRY  SETPRT ^?194,3866
       ENTRY  MSGSEL ^?395,8478
     & intensity1(^?577,12231
       character*(*) function foo(^?579,12307
^L
f-src/entry.strange,171
      LOGICAL FUNCTION PRTPKG ^?2,2
       ENTRY  SETPRT ^?193,3793
       ENTRY  MSGSEL ^?394,8405
     & intensity1(^?576,12158
       character*(*) function foo(^?578,12234

Now, these 3 files have exactly identical contents, and the _only_
difference between the first 2 and the 3rd is that the latter is
gzip-compressed.  So that should be the only reason why all its line
counts are off by 1, and its byte counts are all off by 73, which just
happens to be the length of the first line of the (uncompressed) file.

So could it be that rewinding a 'popen'-created stream doesn't work
correctly on GNU/Linux as well?  If so, we will have to make changes
in etags to not do that, I think, and instead reuse the already-read
stuff as needed.