From: Simon Marchi <simark@simark.ca>
To: svante.signell@gmail.com, Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Please define thread_info as struct thread_info (and other stuff)
Date: Sun, 16 Dec 2018 04:31:00 -0000 [thread overview]
Message-ID: <e88220e4-143b-264b-93f4-f79994a82cf6@simark.ca> (raw)
In-Reply-To: <e4ca5ff1724f9a4d3fb55b681f405cde4a75d22c.camel@gmail.com>
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
next prev parent reply other threads:[~2018-12-16 4:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-15 19:36 Svante Signell
2018-12-15 22:48 ` Tom Tromey
2018-12-15 23:01 ` Svante Signell
2018-12-16 4:31 ` Simon Marchi [this message]
2018-12-16 5:14 ` Svante Signell
2018-12-16 6:02 ` Simon Marchi
2018-12-16 16:22 ` Tom Tromey
2018-12-16 9:20 ` Andreas Schwab
2018-12-16 19:08 ` Svante Signell
2018-12-16 23:10 ` Tom Tromey
2018-12-17 20:51 ` Svante Signell
2018-12-17 21:41 ` John Baldwin
2019-02-14 15:16 ` Thomas Schwinge
2018-12-20 13:31 ` Svante Signell
2018-12-20 22:34 ` Tom Tromey
2018-12-20 23:26 ` Simon Marchi
2018-12-24 21:51 ` Tom Tromey
2019-01-12 18:37 ` Svante Signell
2019-01-12 20:50 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e88220e4-143b-264b-93f4-f79994a82cf6@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=svante.signell@gmail.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox