This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Please define thread_info as struct thread_info (and other stuff)


>>>>> "Svante" == Svante Signell <svante.signell@gmail.com> writes:

>> Try adding a forward declaration of struct thead_info.  Note that
>> config/i386/nm-i386gnu.h includes "regcache.h", making it unique among
>> the nm.h files.

Svante> From what I've leraned forward declarations is bad coding, an should be avoided
Svante> as much as possible. Right or wrong?

Opinions vary -- I think the Google style has a rule against it? -- but
gdb generally does not avoid it.

Svante> Furthermore, not defining thread_info as struct everywhere is in my opinion very
Svante> lazy coding.

I disagree here, C++ provides the typedef, there's nothing really wrong
with using it.

Svante> Another issue is to compile C-code (and C++-code) in *.c files.
Svante> Please rename these to *.cpp (and eventually the header files to *.hpp)! As it
Svante> is now it is very confusing.

I think this was discussed When we made this switch, and the conclusion
was that a mass rename would be worse.

Svante> Finally, I've found the problem (but no workaround yet): thread_info is an RPC
Svante> on GNU/Hurs, and including mach.h in gdb/config/i386/nm-i386gnu.h:#include
Svante> <mach.h> further includes <mach/mach_interface.h> which has the conflicting name
Svante> of that RPC:
Svante> kern_return_t thread_info
Svante> (

Typical answers for this kind of thing are either to segregate the use
of the system header somehow, or maybe namespacing or some other kind of
renaming.  I haven't looked into the details much in this case I'm
afraid.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]