From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16200 invoked by alias); 28 Feb 2014 21:34:01 -0000 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 Received: (qmail 16189 invoked by uid 89); 28 Feb 2014 21:34:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Feb 2014 21:33:59 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SLX98i026067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 16:33:10 -0500 Received: from host2.jankratochvil.net (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1SLX5p7008689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Feb 2014 16:33:08 -0500 Date: Fri, 28 Feb 2014 21:34:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Aleksandar Ristovski Subject: Re: [patchv3 1/8] Move utility functions to common/ Message-ID: <20140228213305.GA2466@host2.jankratochvil.net> References: <20140227213242.GB21121@host2.jankratochvil.net> <53107BBE.6040407@redhat.com> <20140228201055.GA21879@host2.jankratochvil.net> <5310FB60.9030105@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5310FB60.9030105@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00893.txt.bz2 On Fri, 28 Feb 2014 22:10:56 +0100, Pedro Alves wrote: > There are gdb ports out there with TARGET_CHAR_BIT != 8. OK. They do not have to be C90/C99/POSIX. > We don't have any in the tree currently, but I believe most of the code we > have actually works. I wouldn't have a problem with accepting such a port. The problem is you have not accepted such a port. And there is (probably unwritten) rule that any GDB code not required by current codebase can be removed. With a versioning system any code can be easily returned back later. > > already C90 defines CHAR_BIT as constant 8. > > Sorry, but that's not true. I'm looking at N1256 (C99/TC3 draft), > and in 5.2.4.2.1, it shows: > > #define CHAR_BIT 8 > > _but_, it also says just above: > > "The minimum magnitudes shown shall be replaced by implementation-defined > magnitudes with the same sign." > > So that means it must be _at least_ 8-bit, but it also be wider than 8. It may be true but I am not completely sure with it. The whole paragraph is: Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign. Whether "except for CHAR_BIT and MB_LEN_MAX" applies only to the first sentence or even to the last sentence is not clear to me, although it may be more like you say. > I could see deleting HOST_CHAR_BIT, that's a different story. OK. > host-defs.h > already exists, and this being macro representing a fundamental > characteristic of the host, it just feels better than a header > for common string utilities and such. OK, moved it to common/host-defs.h when that file already exists. Thanks, Jan