From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: etags test is broken on MS-Windows Date: Wed, 20 May 2015 18:38:51 +0300 Message-ID: <83a8wz6yyc.fsf@gnu.org> References: <83y4kmdjmj.fsf@gnu.org> <555A8E62.7060700@cs.ucla.edu> <83h9r8egen.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1432136366 27553 80.91.229.3 (20 May 2015 15:39:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 15:39:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Francesco =?iso-8859-1?Q?Potort=EC?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 20 17:39:19 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 1Yv65X-0006E6-9R for ged-emacs-devel@m.gmane.org; Wed, 20 May 2015 17:39:19 +0200 Original-Received: from localhost ([::1]:52879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv65W-0008RW-Pj for ged-emacs-devel@m.gmane.org; Wed, 20 May 2015 11:39:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv65I-0008RN-6n for emacs-devel@gnu.org; Wed, 20 May 2015 11:39:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yv65E-0004Rb-5T for emacs-devel@gnu.org; Wed, 20 May 2015 11:39:04 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:59137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv65D-0004RQ-Tp; Wed, 20 May 2015 11:39:00 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NON00B00NC7S500@a-mtaout20.012.net.il>; Wed, 20 May 2015 18:38:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NON00BNUNGWPW20@a-mtaout20.012.net.il>; Wed, 20 May 2015 18:38:57 +0300 (IDT) In-reply-to: <83h9r8egen.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:186669 Archived-At: > Date: Tue, 19 May 2015 18:27:44 +0300 > From: Eli Zaretskii > Cc: emacs-devel@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?). 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.