From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31884 invoked by alias); 30 Mar 2012 16:14:24 -0000 Received: (qmail 31872 invoked by uid 22791); 30 Mar 2012 16:14:21 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Mar 2012 16:14:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2UGE7Cw019455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Mar 2012 12:14:07 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2UGE3cq001981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 30 Mar 2012 12:14:06 -0400 Date: Fri, 30 Mar 2012 16:14:00 -0000 From: Jan Kratochvil To: gdb@sourceware.org Subject: Will therefore GDB utilize C++ or not? Message-ID: <20120330161403.GA17891@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00087.txt.bz2 Hi, there is now new patch: Re: [PATCH] Allow 64-bit enum values http://sourceware.org/ml/gdb-patches/2012-03/msg00932.html which is a pre-requisite for GDB inferior type fields safety similar to what I already checked in as: [commit] [patch 2/2] typedef-checking for CU relative vs. absolute offsets http://sourceware.org/ml/gdb-patches/2012-03/msg00721.html But compared to the [commit] patch of only 282 '+' lines limited to dwarf* files only above the type fields safety patch will be huge and thorough the whole GDB codebase (TYPE_LENGTH: 1103 lines, FIELD_BITPOS: 22 lines, sure the patch will be larger).. -> This whole effort is wrong if GDB was in C++ which allows to use: http://en.wikipedia.org/wiki/Object_type_%28object-oriented_programming%29#Boxing so that one can directly use type->length as long as it is safe, an example of C++ solution is given below. It no longer needs to patch every use of TYPE_LENGTH into some TYPE_LENGTH_VAL or to append '.cu_off' to every use of the "integer" like I did in the [commit] patch above. There are sure many other cases I still wait to solve using C++. There was some plan to have GDB exceptions and cleanups converted to C++ exceptions and RAII http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization automatic allocation/deallocation which would automatically solve many other bugs being fixed by hand here and there. I have filed also crashes from stale frame_info * http://sourceware.org/bugzilla/show_bug.cgi?id=13866 which would be easily sanity-protected by mandatory referencing frame_info * by C++ smart-pointer and during reinit_frame_cache just assert there are no live instances of frame_info references out there etc. etc. For switching GDB compilation to C++ there is needed to resolve some name clashes first http://sourceware.org/gdb/wiki/ArcherBranchManagement Enabling gdb to compile with the -Wc++-compat flag to gcc. archer-ratmice-compile-Wc++-compat but there is enough workforce to do this mechanical type of work as long as there is an agreement to switch to C++. To C++ or not to C++? Unfortunately the discussion was here already before and I am aware several contributors are not welcome with it, I think it does not need to affect readability of C code much, there is not enough workforce to rewrite all the GDB code into C++ style anyway. Still C++ would help a lot, some kinds of bugs are not solvable without it. I am open to suggestions of static analysis tools to use instead but at least according to the experience of Tom Tromey it is not so easy / safe / foolproof to use, IIUC his words. Thanks, Jan #include class Length { int64_t _x; public: Length(int64_t x) { _x = x; } operator int64_t() { return _x; } private: operator int() { return _x; } }; void ok (int64_t l) {} void bad (int l) {} void bad2 (long long l) {} int main() { Length l(10); // great, no errors ok (l); // error: ‘Length::operator int()’ is private // error: within this context // note: candidates are: // note: Length::operator int() // note: Length::operator int64_t() // error: initializing argument 1 of ‘void bad2(long long int)’ bad (l); // error: conversion from ‘Length’ to ‘long long int’ is ambiguous bad2 (l); }