From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] process/thread/lwp id patch - phase 1 Date: Thu, 03 May 2001 15:57:00 -0000 Message-id: <3AF1E24D.9080306@cygnus.com> References: <1010430174514.ZM31129@ocotillo.lan> X-SW-Source: 2001-05/msg00037.html > * defs.h (ptid_t): New typedef. More of an observation than a comment. GDB doesn't have a policy on how to name what I think have become known as ``light weight types'' along iwth other typedefs. As it is we have xxx_ftype xxx_func I've recently tried to encourage just *_ftype over _func but largely for arbitrary reasons. LONGEST DOUBLEST I suspect these were originally macros. serial_t value_ptr these may be replaced with ``struct xxxx *'' PTR being replaced with ``void *''. and so on. Given this, randomness, someone might someday make it all consistent. However, until that day, as kevin, noted we can probably live with foo_t. Besides, having a type and using it consistently is more important than the name. In terms of direction, I would expect tpid_t to eventually just be treated like a KEY that is used to locate the corresponding ``struct thread_info *'' object. It is a key because GDB retains it for longer than the lifetime of the corresponding thread_info object. With this in mind: > - This patch introduces some new macros, pid_to_ptid, null_ptid, > minus_one_ptid, and ptid_equal. These macros will be eliminated > in phase 3. In their place will be functions (for pid_to_ptid > and ptid_equal) and variables (for null_ptid and minus_one_ptid). > Other ptid accessors an a ptid constructor will be introduced at > the same time. is ptid_equal() needed? Won't memcmp() be sufficient? Andrew