From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: largefile64 on ports Date: Sat, 09 Sep 2006 09:01:10 +1000 Message-ID: <873bb2x8sp.fsf@zip.com.au> References: <87irjz5ks3.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1157756506 23295 80.91.229.2 (8 Sep 2006 23:01:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Sep 2006 23:01:46 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Sep 09 01:01: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 1GLpLm-0005Mb-DJ for guile-devel@m.gmane.org; Sat, 09 Sep 2006 01:01:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLpLl-0004fo-Jc for guile-devel@m.gmane.org; Fri, 08 Sep 2006 19:01:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GLpLh-0004fV-30 for guile-devel@gnu.org; Fri, 08 Sep 2006 19:01:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GLpLd-0004ez-Vl for guile-devel@gnu.org; Fri, 08 Sep 2006 19:01:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLpLd-0004eu-RE for guile-devel@gnu.org; Fri, 08 Sep 2006 19:01:21 -0400 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GLpMK-00052N-5v for guile-devel@gnu.org; Fri, 08 Sep 2006 19:02:04 -0400 Original-Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 470D65A7E62; Sat, 9 Sep 2006 09:01:16 +1000 (EST) Original-Received: from localhost (ppp2327.dyn.pacific.net.au [61.8.35.39]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k88N1DaD015528; Sat, 9 Sep 2006 09:01:14 +1000 Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1GLpLT-0001vK-0L; Sat, 09 Sep 2006 09:01:11 +1000 Original-To: Greg Troxel Mail-Copies-To: never In-Reply-To: (Greg Troxel's message of "Fri, 08 Sep 2006 09:25:38 -0400") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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:6069 Archived-At: Greg Troxel writes: > > Is there any good reason to just not use the 64-bit calls all the time > if they exist? I did that for file descriptors and filenames, the ports are the hold-out. > 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. glibc has kept off_t at 32-bits, I suspect solaris is the same (without being much worried about that system). > Is _LARGEFILE64 a glibc/Linux thing, or is it broader than that? Are > there any relevant standards? The single-unix spec http://www.unix.org/version2/whatsnew/lfs20mar.html Perhaps netbsd has made that transition the default system-wide ("#define _LARGEFILE_SOURCE" in essense). > 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. Exporting the 64-bit would be a bonus, letting applications on gnu systems do 64-bit files the same as guile (will). > 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. Yep, I did that for the simple bits. "open_or_open64" and friends are, as their names suggest, the one or the other function according to what's available. > But now I realize the point is about the C interface labeled SCM_, and > I see why this is much harder. Yep, the problem is that mucking about with off_t breaks source and binary compatibility in the port type descriptor structure seek and truncate function fields. If those two weren't exposed, or if they were size_t or something, then it would have been as easy as flicking the _LARGEFILE_SOURCE switch, as intended for most applications. > 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. > I don't follow SCM_HAVE_LARGEFILE64; grepping for it in CVS comes up > empty. To be added in a configure test. Another name like SCM_HAVE_OFF64_T would be a possibility, it'd be in the public scmconfig.h. > 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. > ... > Yes, people have to rebuild, and they'll have to change their source > slightly, That's what I'd like to avoid. I think asking for source changes in application code should be a last resort. I'd probably prefer just to make some internal changes for now if exposing the 64-bit funcs is too controversial. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel