From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20351 invoked by alias); 18 Jul 2006 13:15:15 -0000 Received: (qmail 20296 invoked by uid 22791); 18 Jul 2006 13:15:11 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr1.xs4all.nl (HELO smtp-vbr1.xs4all.nl) (194.109.24.21) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Jul 2006 13:15:07 +0000 Received: from webmail.xs4all.nl (dovemail10.xs4all.nl [194.109.26.12]) by smtp-vbr1.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6IDExk7047926; Tue, 18 Jul 2006 15:14:59 +0200 (CEST) (envelope-from mark.kettenis@xs4all.nl) Received: from 192.87.1.22 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Tue, 18 Jul 2006 15:14:59 +0200 (CEST) Message-ID: <22754.192.87.1.22.1153228499.squirrel@webmail.xs4all.nl> In-Reply-To: <20060718123436.GB14653@nevyn.them.org> References: <200607181356.16071.vladimir@codesourcery.com> <24758.192.87.1.22.1153221922.squirrel@webmail.xs4all.nl> <20060718123436.GB14653@nevyn.them.org> Date: Tue, 18 Jul 2006 13:15:00 -0000 Subject: Re: [PATCH] zero-terminate result of target_read_alloc From: "Mark Kettenis" To: "Mark Kettenis" , "Vladimir Prus" , gdb-patches@sources.redhat.com User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/msg00229.txt.bz2 > 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. > > I figured the same but actually reading a couple of objects and > managing them convinced me that Volodya's right. Note that he's not > adding one to the length returned - if you want binary data, you'll get > binary data. It just allows you to easily treat the result as a string > if you plan to treat it as a string anyway. Sorry, but the whole distinction between strings and binary data is wrong. Strings are binary data, including the terminating NUL. Volodya's patch addresses things at the wrong level. Whatever we read using target_read_partial() should already include the terminating NUL. > As you can probably guess from context, we have these bunches of XML > files that we read from the target and then do text processing on. > On the branch where I developed the XML bits for the first time, I > didn't think to make this change - so the very first thing I had to do > with the result of target_read_alloc was to allocate something one byte > bigger with a NUL on the end of it! So whatever reads the XML from the target should make sure things are NUL-terminated, and report the total length, including the terminating NUL. I guess you're thinking too much in terms of the remote protocol, where you need to make the distinction between text and binary data because you have to encode the latter to avoid problems with embedded NUL's. But that's really specific to the way our remote protocol works, and therefore should be handled completely in the remote target vector code. Mark