Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 01 Sep 2010 20:39:52 +0200, Joel Brobecker wrote:
> > These were the reasons for the typedef but I do not mind and I can
> > monkey-patch whatever gets agreed upon and be done with this part which
> > accidentally became a code cleanup only patch.
> 
> I'm not against the typedef at all :). I was just thinking that
> perhaps we could leave the enum alone as one component of the struct
> (be it typedef'ed).

The patches of mine re-introduce (in [patch 3/9]#2) former
`enum target_signal' as `enum target_signal_number'.

Keeping the `enum target_signal' name would contradict (**) the sole remaining
meaning of the [patch 3/9]#2 patch (*) - making target_signal and
`int host_signal' type incompatible catching various bugs in the current code.

(*) After it stopped to be a pre-requisite for the [rfc 7/9]#2 patch.

(**) While it is easy to ensure no `enum target_signal' remains used/misplaced
     in the current code it would not get protected against all the 3rd party
     patches floating around out there reintroducing the same problem in the
     future.

`enum target_signal_number' is a new type and it is used only on very few
places where the user is fortunately careful enough not to misplace it with
`int host_signal'.  On other places `target_signal_t' is now a struct
naturally type-incompatible with `int host_signal'.


Thanks,
Jan