[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: etags test is broken on MS-Windows
From: |
Francesco Potortì |
Subject: |
Re: etags test is broken on MS-Windows |
Date: |
Thu, 21 May 2015 15:24:44 +0200 |
>> (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.
- Re: etags test is broken on MS-Windows, Eli Zaretskii, 2015/05/19
- Re: etags test is broken on MS-Windows, Francesco Potortì, 2015/05/21
- Re: etags test is broken on MS-Windows, Eli Zaretskii, 2015/05/21
- Re: etags test is broken on MS-Windows, Paul Eggert, 2015/05/21
- Re: etags test is broken on MS-Windows, Eli Zaretskii, 2015/05/21
- Re: etags test is broken on MS-Windows, Paul Eggert, 2015/05/21
- Re: etags test is broken on MS-Windows, Eli Zaretskii, 2015/05/21
- Re: etags test is broken on MS-Windows, Paul Eggert, 2015/05/21
- Re: etags test is broken on MS-Windows, Eli Zaretskii, 2015/05/22