From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11239 invoked by alias); 28 Jun 2006 08:18:26 -0000 Received: (qmail 11193 invoked by uid 22791); 28 Jun 2006 08:18:21 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Jun 2006 08:18:16 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FvVFR-00025M-Pl for gdb-patches@sources.redhat.com; Wed, 28 Jun 2006 10:18:09 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jun 2006 10:18:09 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jun 2006 10:18:09 +0200 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [rfc] Correct semantics of target_read_partial, add target_read_whole Date: Wed, 28 Jun 2006 08:18:00 -0000 Message-ID: References: <20060622032355.GA27566@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00386.txt.bz2 Daniel Jacobowitz wrote: > +/* Wrappers to perform a full read of unknown size. OBJECT/ANNEX will > + be read using OPS. The return value will be -1 if the transfer > + fails or is not supported; 0 if the object is empty; and the length > + of the object otherwise. If a positive value is returned, a > + sufficiently large buffer will be allocated using xmalloc and > + returned in *BUF_P containing the contents of the object. > + > + This method should be used for objects sufficiently small to store > + in a single xmalloced buffer, when no fixed bound on the object's > + size is known in advance. Don't try to read TARGET_OBJECT_MEMORY > + through this function. */ > + > +extern LONGEST target_read_whole (struct target_ops *ops, > + enum target_object object, > + const char *annex, gdb_byte **buf_p); Is there any reason why 'target_read_whole' calls 'target_read', as opposed to calling 'target_read_partial' directly? I mean, if target_read_whole can do several reads itself, there's no point to use 'target_read'. - Volodya