Re: [PATCH RFC] process/thread/lwp id patch - phase 1

[Andrew Cagney <ac131313@cygnus.com>]

>  * 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