Re: etags test is broken on MS-Windows

["Francesco Potortì" <pot@gnu.org>]

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

Yes, that's it.  I implemented the gzip feature myself, and I included
tests for it.  A source file should produce the same tags whether
compressed or not.

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

This is a bug.

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

It could well be.  It may have happened that, when I checked that the
TAGS files were the same, I just looked at them without running diff and
I missed this discrepancy.