From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2059 invoked by alias); 27 Sep 2003 16:06:11 -0000 Mailing-List: contact overseers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: , Sender: overseers-owner@sources.redhat.com Received: (qmail 2052 invoked from network); 27 Sep 2003 16:06:11 -0000 Received: from unknown (HELO snow.csi.cam.ac.uk) (131.111.8.15) by sources.redhat.com with SMTP; 27 Sep 2003 16:06:11 -0000 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A3HaC-00017S-Uq; Sat, 27 Sep 2003 17:06:08 +0100 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.35 #1 (Debian)) id 1A3HaC-00063F-00; Sat, 27 Sep 2003 17:06:08 +0100 Date: Sat, 27 Sep 2003 16:06:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@kern.srcf.societies.cam.ac.uk To: Hans-Peter Nilsson cc: Christopher Faylor , overseers@sources.redhat.com Subject: Re: last days of htdig In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-SW-Source: 2003-q3/txt/msg00234.txt.bz2 On Sat, 27 Sep 2003, Hans-Peter Nilsson wrote: > Off the top of my head, I think gnu "sort", sizeof int and > sizeof long (or if we're lucky, just size_t :-) would be the > obvious open sores^Wissues. GNU utilities have been compiling by default with -D_FILE_OFFSET_BITS=64 for ages (though this doesn't help if they would need too much memory, just with large files). The problem would be whether htdig (and any libraries it uses) is clean about using off_t where appropriate (including not using library interfaces such as fseek and ftell, in their place fseeko and ftello) and whether it needs too much memory. And the large files support in many of the GNU utilities probably isn't much exercised beyond their testsuites. Glibc hides the question of what kernel you're running on from the program - a program built to use large-files interfaces doesn't itself need to be built with a >= 2.4 kernel, it just needs to be run under one with a glibc built against headers from one, and if either of the conditions fails at runtime there will just be errors when a file would get too large. -- Joseph S. Myers jsm@polyomino.org.uk