This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] process/thread/lwp id patch - phase 1
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH RFC] process/thread/lwp id patch - phase 1
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 03 May 2001 18:57:17 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <1010430174514.ZM31129@ocotillo.lan>
> * 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