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: Fri, 08 Sep 2006 09:25:38 -0400 Message-ID: References: <87irjz5ks3.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1347166169==" X-Trace: sea.gmane.org 1157722005 1197 80.91.229.2 (8 Sep 2006 13:26:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Sep 2006 13:26:45 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 08 15:26:44 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 1GLgMg-0002mM-Vm for guile-devel@m.gmane.org; Fri, 08 Sep 2006 15:25:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLgMg-0003F9-Ay for guile-devel@m.gmane.org; Fri, 08 Sep 2006 09:25:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GLgMa-0003A5-4B for guile-devel@gnu.org; Fri, 08 Sep 2006 09:25:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GLgMZ-000389-Cr for guile-devel@gnu.org; Fri, 08 Sep 2006 09:25:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLgMZ-00037V-7A for guile-devel@gnu.org; Fri, 08 Sep 2006 09:25:43 -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 1GLgNA-0000yd-FB for guile-devel@gnu.org; Fri, 08 Sep 2006 09:26:20 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 563A452FC; Fri, 8 Sep 2006 09:25:42 -0400 (EDT) Original-To: guile-devel@gnu.org X-Hashcash: 1:20:060908:guile-devel@gnu.org::X8gue+tJGkfcEBRk:000000000000000000000000000000000000000000A3sP In-Reply-To: <87irjz5ks3.fsf@zip.com.au> (Kevin Ryde's message of "Fri, 08 Sep 2006 09:17:32 +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:6067 Archived-At: --===============1347166169== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable What does POSIX say about all of this? My quick reaction is that this is all rather messy. Is there any good reason to just not use the 64-bit calls all the time if they exist? On NetBSD, lseek(2) is said to be POSIX compliant: LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include off_t lseek(int fildes, off_t offset, int whence); STANDARDS The lseek() function conforms to ISO/IEC 9945-1:1990 (``POSIX.1''). And off_t is __int64_t. (It used to be 32 long long ago in 4.3BSD, and there is binary compatability for the old syscall #.) What does Solaris do? I looked on the web and couldn't figure out if one has to use different calls or if they've just changed off_t to 64 bits. Is _LARGEFILE64 a glibc/Linux thing, or is it broader than that? Are there any relevant standards? After looking, I'd say that the code should work ok on systems with 64-bit off_t because it's reasonable for systems to just have 64-bit off_t (and I'd argue preferable; Solaris and glibc docs seem to agree), the whole mess of having separate system calls should not be exported to guile users. So, I'd say that via configure one should find the large calls if they exist, and #define open_large to them, or to open if not present, etc. and then have all the rest of the code just live with 64-bit off_t (which I realize may be off64_t on some systems). But now I realize the point is about the C interface labeled SCM_, and I see why this is much harder. 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. Another approach would be to tell the C library to use the 64-bit types instead of the dual-function transitional approach, but I suppose that impacts programs that include a guile .h but do other things. I don't follow SCM_HAVE_LARGEFILE64; grepping for it in CVS comes up empty. The two competing goals are keeping source and binary compatibility nad having a clean interface. The scheme way is to just have a function that takes a number, so the SCM api should follow that as far as it can. Perhaps we can define scm_off_t as uint64_t, and just have scm_foo calls that use that only 64 bits. Or both, and deprecate the old ones. There should be only one right way to right code that uses the SCM_API, and that way should use 64-bit offsets always, with the other ways marked as deprecated. guile has a long history of compatibility trouble across upgrades, such that worrying about ABI compat seems like a lost cause. My view is that if we keep ABI compat with a release series (and 1.8.0 doesn't count), then as long as there's little API pain across series, that's ok. So if there's scm_off_t defined, and the calls just change to use it (and thus become 64-bit), that seems like the best way forward. Yes, people have to rebuild, and they'll have to change their source slightly, but then we have something reasonable going forward. This sort of change is pretty easy for users: just look for scm_off_t defined and if so use it; if not #define scm_off_t to off_t (and be limited to 32 bits on systems where off_t is 32 bits). If there isn't much code using ports from C, then this won't cause too much pain. Exposing the 32/64 bit variants of these functions seems likely to lead to greater long-term pain. =2D-=20 Greg Troxel --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (NetBSD) iD8DBQFFAW9W+vesoDJhHiURAsSCAKCrWE45L4M7/I/L9xLxigLsPNkoJwCeMsU9 eMgqy5Ql7W4Sh6Mu90b+hro= =YC0F -----END PGP SIGNATURE----- --=-=-=-- --===============1347166169== 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 --===============1347166169==--