From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13814 invoked by alias); 28 Feb 2003 15:47:39 -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 13807 invoked from network); 28 Feb 2003 15:47:38 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 28 Feb 2003 15:47:38 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1SFlce05673 for ; Fri, 28 Feb 2003 10:47:38 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1SFlbQ00519 for ; Fri, 28 Feb 2003 10:47:38 -0500 Received: from cygbert.vinschen.de (vpn50-22.rdu.redhat.com [172.16.50.22]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h1SFlan25047 for ; Fri, 28 Feb 2003 07:47:36 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h1SFlUc14645 for gdb-patches@sources.redhat.com; Fri, 28 Feb 2003 16:47:30 +0100 Date: Fri, 28 Feb 2003 15:47:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA]: File-I/O patch, Documentation Message-ID: <20030228154730.GK20955@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20021121100443.U24928@cygbert.vinschen.de> <3E5D4C4C.1040502@redhat.com> <20030227083701.GE20955@cygbert.vinschen.de> <3E5E9A1A.9000708@redhat.com> <20030228083308.GG24097@cygbert.vinschen.de> <3E5F807D.9080506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5F807D.9080506@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00811.txt.bz2 On Fri, Feb 28, 2003 at 10:30:05AM -0500, Andrew Cagney wrote: > The problem is that the protocol spec isn't self contained. As best as > I can tell, the specification is making assumptions about the underlying > characteristics of `int', `long', `time_t', et.al. types. `int', for > instance, can be anything from 16 to 64 bits. Huh? This is explicitely defined in the chapter "Integral datatypes" which is the chapter mistakenly defined as B.1. See below. > >>The byte order of all the values should be defined. > > > >It is. Quote from the text: > > > > Structured data which is transferred using a memory read or write > > packet as e.g. a struct stat is expected to be in a protocol specific > > format with all numerical multibyte datatypes being big endian. > > If it is defined somewhere else, then cross references are needed. So why don't you say this? You read the document, I assume. But you told that as if it's not in the document. That's a difference I couldn't get from what you wrote. > >>The reference to B.1 should be removed. > Er, `B.1' is meaningless. If the intent was to reference another > section of the document, then a texinfo cross-reference should be used. Sic, yes. It's just a textual reference which I got wrong. This has nothing to do with content which your reply implied to me. Sorry to say that but it's hard to understand what you're up to if your answers are that short. My mind-reading skills got a little bit rusty... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com