From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14114 invoked by alias); 24 Nov 2008 18:35:22 -0000 Received: (qmail 14036 invoked by uid 22791); 24 Nov 2008 18:35:20 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 18:34:37 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw1.br.ibm.com (Postfix) with ESMTP id 0C84532C213 for ; Mon, 24 Nov 2008 16:31:17 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAOJY2vS3694762 for ; Mon, 24 Nov 2008 16:34:02 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAOIYLT3021892 for ; Mon, 24 Nov 2008 16:34:26 -0200 Received: from [9.8.7.183] ([9.8.7.183]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAOIYIwn021843; Mon, 24 Nov 2008 16:34:18 -0200 Subject: Re: [RFA] Add la_getstr member to language_defn From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: gdb-patches ml In-Reply-To: <20081124022858.GA19331@caradoc.them.org> References: <1227417278.28256.183.camel@localhost.localdomain> <20081123161013.GA15069@caradoc.them.org> <1227490821.8533.25.camel@hotblack.bauerhaus> <20081124022858.GA19331@caradoc.them.org> Content-Type: text/plain; charset=UTF-8 Date: Mon, 24 Nov 2008 20:22:00 -0000 Message-Id: <1227551659.28256.225.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00653.txt.bz2 El dom, 23-11-2008 a las 21:28 -0500, Daniel Jacobowitz escribió: > On Sun, Nov 23, 2008 at 11:40:21PM -0200, Thiago Jung Bauermann wrote: > > The comment is wrong. c_getstr actually reads until a null character is > > found, but doesn't read past the end of an array with known length. I > > updated the comment to reflect that. > > > > Except that there was a bug for GDB-hosted strings, in which case the > > function behaved as described by the comment. I fixed it now. > > Are you sure? I took a look at read_string and its comments and it > seemed to do what I described - but I might be wrong. > > + If LEN is -1, stops at the first null character (not necessarily the first > + null byte) up to a maximum of FETCHLIMIT characters, otherwise reading > + proceeds (including null characters) until LEN characters have been read. > + Set FETCHLIMIT to UINT_MAX to read as many characters as possible from the > + string. c_getstr allways passes -1 as the LEN argument, and if the length of the array is known, it passes the length as FETCHLIMIT. If it is not known, FETCHLIMIT will be UINT_MAX (actually, the code currently passes -1, I'll change it to pass UINT_MAX explicitly). Would the comment above be clearer if it read as follows? If LEN > 0, reads exactly LEN characters (including eventual NULs in the middle or end of the string). If LEN is -1, stops at the first null character (not necessarily the first null byte) up to a maximum of FETCHLIMIT characters. Set FETCHLIMIT to UINT_MAX to read as many characters as possible from the string. By the way, I just realised that if LEN is 0, BUFFER is not allocated, contradicting the property I mention in the comment that "unless an exception is thrown, BUFFER will always be allocated, even on failure". I'll change it to allocate a 1 byte buffer in this case, to keep the caller's life simple. -- []'s Thiago Jung Bauermann IBM Linux Technology Center