From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23207 invoked by alias); 24 Jul 2006 21:41:38 -0000 Received: (qmail 23198 invoked by uid 22791); 24 Jul 2006 21:41:37 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Jul 2006 21:41:35 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k6OLcPvn012700; Mon, 24 Jul 2006 23:38:25 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6OLcP90002489; Mon, 24 Jul 2006 23:38:25 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k6OLcP7h023940; Mon, 24 Jul 2006 23:38:25 +0200 (CEST) Date: Mon, 24 Jul 2006 21:41:00 -0000 Message-Id: <200607242138.k6OLcP7h023940@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: vladimir@codesourcery.com, gdb-patches@sources.redhat.com In-reply-to: <20060724040937.GA24339@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 24 Jul 2006 00:09:37 -0400) Subject: Re: [PATCH] zero-terminate result of target_read_alloc References: <200607181356.16071.vladimir@codesourcery.com> <24758.192.87.1.22.1153221922.squirrel@webmail.xs4all.nl> <20060724040937.GA24339@nevyn.them.org> 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-07/txt/msg00365.txt.bz2 > Date: Mon, 24 Jul 2006 00:09:37 -0400 > From: Daniel Jacobowitz > > On Tue, Jul 18, 2006 at 01:25:22PM +0200, Mark Kettenis wrote: > > > > > > This patch makes result of target_read_alloc zero-terminated. > > > The point is that often the object is not allowed to contain embedded > > > zeros, > > > and working with zero-terminated strings is much easier. > > > > > > OK? > > > > This is wrong. Either the terminating nul is part of the object you're > > reading or it is not. GDB shouldn't at its own. > > Hi Mark, > > There was some followup discussion on this, and we didn't hear back > from you. My own explanation of the current behavior is that this is > an interface for reading binary data from the target, much like reading > it from files, so it shouldn't be NUL terminated - but the client may > expect the data to not contain embedded NULs and we have the > opportunity to be helpful here, so we should be helpful. Sorry, yes. I didn't manage to reply yet. I don't find the arguments very convincing. You try to justify the interface by giving examples of interfaces that are very different from target_read_alloc() (and much more similar to target_read()). > Do you find that convincing? If not, would you be happier if there > were two functions to do this, one which added the NUL and one which > did not? I'm thinking target_read_alloc and target_read_stralloc, > indicating that we allocate the result as if it were a string. That seems a reasonably compromise to me. It makes things much more explicit. I think you should go one step further, and make target_read_stralloc() return "char *" instead of "LONGEST" (and do away with the "gdb_byte **" argument). That'd solve the issue whether the length returned includes the terminating NUL or not. The function would return a NULL pointer upon failure and an empty string on (the equivalent of) EOF. Mark