From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23421 invoked by alias); 29 Jan 2008 16:20:41 -0000 Received: (qmail 23412 invoked by uid 22791); 29 Jan 2008 16:20:40 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 16:20:19 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id m0TGKAOA005661 for ; Tue, 29 Jan 2008 16:20:10 GMT Received: from rv-out-0910.google.com (rvbk15.prod.google.com [10.140.87.15]) by zps38.corp.google.com with ESMTP id m0TGK8NB014934 for ; Tue, 29 Jan 2008 08:20:09 -0800 Received: by rv-out-0910.google.com with SMTP id k15so1759395rvb.14 for ; Tue, 29 Jan 2008 08:20:08 -0800 (PST) Received: by 10.140.133.16 with SMTP id g16mr4496925rvd.231.1201623607952; Tue, 29 Jan 2008 08:20:07 -0800 (PST) Received: by 10.141.186.16 with HTTP; Tue, 29 Jan 2008 08:20:07 -0800 (PST) Message-ID: Date: Tue, 29 Jan 2008 16:24:00 -0000 From: "Doug Evans" To: "GDB Patches" , "Pierre Muller" Subject: Re: [BUG] BINOP_DIV and ptyp command In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002301c85c12$a73a4640$f5aed2c0$@u-strasbg.fr> <20080129134609.GB22342@caradoc.them.org> 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-01/txt/msg00683.txt.bz2 On Jan 29, 2008 8:03 AM, Doug Evans wrote: > I can't tell if that's a fun comment for grin's sake or not. I can > flip my pedantic bit and argue the same thing. Obviously "ptype > int+int" is "int". > > In this particular case having to hack whatis-exp.exp to "pass" until > the general bug is fixed is ok by me - is anyone relying on ptype 4/2 > to be int whereas ptype 4*2 is long? For completeness' sake, while my pedantic bit is flipped, One premise of this particular comment is that it assumes one particular definition of EVAL_AVOID_SIDE_EFFECTS. If E_A_S_E is indeed intended to mean to avoid calling error() (which isn't unreasonable), then that changes the premise. To make progress here (and those who have worked on gdb longer probably know the complete definition of E_A_S_E already - they take it as a given - I can't) it would be nice to at least have a full and correct definition of EVAL_AVOID_SIDE_EFFECTS at its definition site.