From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32632 invoked by alias); 13 Dec 2002 15:33:14 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32622 invoked from network); 13 Dec 2002 15:33:10 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 13 Dec 2002 15:33:10 -0000 Received: from dberlin.org (h-69-3-5-6.MCLNVA23.covad.net [69.3.5.6]) by mail.cdt.org (Postfix) with ESMTP id 3CBA54900D1; Fri, 13 Dec 2002 10:30:34 -0500 (EST) Received: from [192.168.1.102] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0.2) with ESMTP-TLS id 1810788; Fri, 13 Dec 2002 10:33:03 -0500 Date: Fri, 13 Dec 2002 07:33:00 -0000 Subject: Re: *****SPAM***** casting in gdb Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Jacques Le Normand" From: Daniel Berlin In-Reply-To: <002301c2a270$e82f3540$c11ffea9@ehville> Message-Id: <2ADB5EBD-0EB0-11D7-8880-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00199.txt.bz2 On Friday, December 13, 2002, at 01:28 AM, Jacques Le Normand wrote: > how do you get gdb to cast to size_t? > I realize that size_t is a typedef to unsigned long long or somesuch. > A little background: > when I'm debugging my vector v, gdb won't let me type v[0], > instead = > it says this: "One of the arguments you tried to pass to operator[] = > could not be converted to what the funtion wants." > I then looked up what operator[] took in the sgi docs and it said a = > size_t. Anyone have any ideas? > (I realize I can do p *(v._M_start+n) , but having a method for > casting = > would help me later on) > --Jacques > While this doesn't help *you*, it should help the current C++ people for GDB: I've seen this with STABS debugging info when some of the operator functions were left out of the debugging info, but others weren't (GCC + STABS will omit unused functions from debug info), and we ommitted the operator we really need to use, and in some cases when we parsed the types of the arguments out of the demangled function name and come up with some weird type. >