From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26692 invoked by alias); 28 Dec 2003 23:38:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26685 invoked from network); 28 Dec 2003 23:38:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 28 Dec 2003 23:38:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AakTw-0000FS-Dg; Sun, 28 Dec 2003 18:38:00 -0500 Date: Sun, 28 Dec 2003 23:38:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Fix compilation failure of remote-fileio.c Message-ID: <20031228233800.GA815@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00500.txt.bz2 On Sun, Dec 28, 2003 at 03:52:13PM +0200, Eli Zaretskii wrote: > remote-fileio.c won't compile if `struct stat' doesn't have the > `st_blocks' member. The patch below fixes that, but I'm not sure it > (and the associated patch to gdb/configure.in, which is not shown > below) is the right fix. Is it perhaps better not to use st_blocks at > all, and instead compute the number of blocks as shown by the patch, > for all platforms? Probably not. If it's correct for DJGPP then it's a bit of an accident. The reason it isn't correct in general: blksize_t st_blksize; /* blocksize for filesystem I/O */ blkcnt_t st_blocks; /* number of blocks allocated */ It's not clear from those comments, but st_blksize is the "optimal IO size": The value st_blocks gives the size of the file in 512-byte blocks. (This may be smaller than st_size/512 e.g. when the file has holes.) The value st_blksize gives the "preferred" blocksize for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.) So you probably want st->st_size / 512 instead. > +#else > + remote_fileio_to_fio_ulong ((LONGEST) st->st_size / (LONGEST) st->st_blksize > + + ((LONGEST) st->st_size % (LONGEST) st->st_blksize) != 0, > + fst->fst_blocks); > +#endif A marginally more efficient way to write this is: ((LONGEST) st->st_size + st->st_blksize - 1) / st->st_blksize -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer