From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111782 invoked by alias); 16 Dec 2018 04:31:29 -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 111607 invoked by uid 89); 16 Dec 2018 04:31:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=history, throughout, HContent-Transfer-Encoding:8bit X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Dec 2018 04:31:10 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 92ABF1E093; Sat, 15 Dec 2018 23:31:08 -0500 (EST) Subject: Re: [PATCH] Please define thread_info as struct thread_info (and other stuff) To: svante.signell@gmail.com, Tom Tromey Cc: gdb-patches@sourceware.org References: <87tvje5rvh.fsf@tromey.com> From: Simon Marchi Message-ID: Date: Sun, 16 Dec 2018 04:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-12/txt/msg00177.txt.bz2 On 2018-12-15 6:01 p.m., Svante Signell wrote: > A typical error output: > CXX target.o > /home/srs/DEBs/gdb/gdb-8.2/gdb/target.c: In function ‘int > dispose_inferior(inferior*, void*)’: > /home/srs/DEBs/gdb/gdb-8.2/gdb/target.c:2028:16: error: ‘thread’ was not > declared > in this scope > thread_info *thread = any_thread_of_inferior (inf); > ^~~~~~ > /home/srs/DEBs/gdb/gdb-8.2/gdb/target.c:2028:16: note: suggested alternative: > ‘myread’ > thread_info *thread = any_thread_of_inferior (inf); > ^~~~~~ > myread > > Sorry, but the compiler directive is hidden from the output (by libtool??). You can do "make V=1" to show the compiler invocation (same as if we would use automake). > > ii gcc 4:8.2.0-2 hurd-i386 GNU C compiler > ii g++ 4:8.2.0-2 hurd-i386 GNU C++ compiler > > I would be very happy if you could be consistent in the coding: Either use > struct thread_info everywhere or not. Well, we started with the "struct" keyword everywhere (because C), and many people get rid of it in the parts of the code they touch (though not everyone, and I don't turn down a patch just for this). We also won't make a big change to remove the use of "struct" throughout, as it would be a lot of work for nothing, it would create unnecessary conflicts for people who maintain external patches and it would pollute the history when git-blaming. What you compiler is doing is very strange, as Tom mentioned the use of the "struct" or "class" keyword when declaring a variable in C++ is optional. What does your compiler say when compiling the following code (g++ -c foo.cpp)? struct Foo { int a; }; void func() { Foo f2; } Simon