From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: largefile64 on ports Date: Sat, 09 Sep 2006 19:59:33 -0400 Message-ID: References: <87irjz5ks3.fsf@zip.com.au> <873bb2x8sp.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1113401972==" X-Trace: sea.gmane.org 1157846392 7412 80.91.229.2 (9 Sep 2006 23:59:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 9 Sep 2006 23:59:52 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 10 01:59:51 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GMCjk-0005BW-Bi for guile-devel@m.gmane.org; Sun, 10 Sep 2006 01:59:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMCjj-0004yu-S7 for guile-devel@m.gmane.org; Sat, 09 Sep 2006 19:59:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMCjg-0004yI-J5 for guile-devel@gnu.org; Sat, 09 Sep 2006 19:59:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMCjc-0004x5-FY for guile-devel@gnu.org; Sat, 09 Sep 2006 19:59:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMCjc-0004ww-AQ for guile-devel@gnu.org; Sat, 09 Sep 2006 19:59:40 -0400 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GMCkX-000251-Hz for guile-devel@gnu.org; Sat, 09 Sep 2006 20:00:37 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 5E7C35286; Sat, 9 Sep 2006 19:59:39 -0400 (EDT) Original-To: guile-devel@gnu.org X-Hashcash: 1:20:060909:guile-devel@gnu.org::aDihKh+EGElibtAL:0000000000000000000000000000000000000000000bzC In-Reply-To: <873bb2x8sp.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 09 Sep 2006 09:01:10 +1000") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6073 Archived-At: --===============1113401972== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= I see your points, but it still seems really gross to impose the two sets of calls, esp. in 2006 when the transitional API should have been transitioned already (with simply having 64-bit off_t all the time, and ABI compat for old programs via syscall renumbering). I think it's important that systems with native 64-bit off_t programs still work and don't need to do anything special. I suppose the foo64 calls will just be the same as the regular calls, and guile can somehow default to that. So guile-using programs that are aware of the foo64 method slots and those that don't should both work, including for files of >32 bit size. I think your patch does that; if there are no foo64 syscalls then foo is used, and with off_t, so things should be fine. Am I following correctly? > I see in ports.c that _LARGEFILE64_SOURCE is defined. As far as I can > tell, this is a glib thing rather than a standard thing and thus > should be ifdefed. Should do nothing anywhere it's unrecognised or unsupported. Probably, but still this is namespace pollution at best. _LARGEFILE64_SOURCE doesn't show up in the SUS document you referred me to. (Thanks for the link; I didn't know about this before. I think 4.4BSD chose to just make off_t 64-bit and skip the transitional API. In retrospect that was clearly the right move - all this pain is simply skipped, and old programs run fine. But I realize that's not the question on the table.) So IMHO a configure test is in order for this. But it's not a big deal. I don't mean to sound super cranky - thanks for making guile better. gdt, guile-devel standards/portability crank --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (NetBSD) iD8DBQFFA1Vr+vesoDJhHiURApQcAJ9Uk44pNFFXd/Xh5WKHg6V3TvWIGQCfbW08 yziNXOwy/tgq1pdOn9Dk3+I= =qu88 -----END PGP SIGNATURE----- --=-=-=-- --===============1113401972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel --===============1113401972==--