From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Francesco =?utf-8?Q?Potort=C3=AC?= Newsgroups: gmane.emacs.devel Subject: Re: etags test is broken on MS-Windows Date: Thu, 21 May 2015 15:24:44 +0200 Message-ID: References: <83y4kmdjmj.fsf@gnu.org> <555A8E62.7060700@cs.ucla.edu> <83h9r8egen.fsf@gnu.org> <83a8wz6yyc.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1432214726 13062 80.91.229.3 (21 May 2015 13:25:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 13:25:26 +0000 (UTC) Cc: Paul Eggert , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 21 15:25:18 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YvQTL-0008T1-OP for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 15:25:16 +0200 Original-Received: from localhost ([::1]:57697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvQTK-0001cf-Lg for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 09:25:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvQT1-0001Zb-8e for emacs-devel@gnu.org; Thu, 21 May 2015 09:24:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvQSy-0001lk-T1 for emacs-devel@gnu.org; Thu, 21 May 2015 09:24:55 -0400 Original-Received: from blade3.isti.cnr.it ([194.119.192.19]:31219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvQSt-0001jJ-6N; Thu, 21 May 2015 09:24:47 -0400 Original-Received: from tucano.isti.cnr.it ([146.48.81.102]) by mx.isti.cnr.it (PMDF V6.5-x6 #32097) with ESMTPSA id <01PM8OO7J5QELZNNMY@mx.isti.cnr.it>; Thu, 21 May 2015 15:24:43 +0200 (MEST) Original-Received: from pot by tucano.isti.cnr.it with local (Exim 4.85) (envelope-from ) id 1YvQSq-0005SX-0e; Thu, 21 May 2015 15:24:44 +0200 In-reply-to: <83a8wz6yyc.fsf@gnu.org> X-INSM-ip-source: 146.48.81.102 Auth Done X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.119.192.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186699 Archived-At: >> (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.