On Thu, 02 Sep 2010 03:54:47 +0200, Pedro Alves wrote: > The rest of the idea remains. A target_signal_o array to hold > all the possible gdb signals, and a target_signal becomes: > > typedef const struct target_signal_o * target_signal; While trying to clean it up for a check-in I found it as a no-go. The current GDB code assumes zeroed target_signal field is TARGET_SIGNAL_0. Additionally literal `0' is also compatible with such target_signal type. While sure one can try to find such places of implicit zeroed initializations it may more destabilize the GDB codebase than what the code-neutral compile time sanity checking goal should have reached. 5192 resume (currently_stepping (ecs->event_thread), 5193 ecs->event_thread->stop_signal); -> #6 0x000000000069cc5e in resume (step=0, sig=0x0) at infrun.c:1743 (gdb) p sig $9 = (gdb_target_signal_t) 0x0 The struct { } solution [patch 3/9]#2 Change target_signal_t to a struct http://sourceware.org/ml/gdb-patches/2010-08/msg00483.html had (unintentionally?) TARGET_SIGNAL_0 equivalent to a zeroed memory block. Another possibility would be to make it a `(type *) 0L', `(type *) 1L' etc. But in general if TARGET_SIGNAL_EQ() etc. operators are not acceptable I find mostly the compile-time sanity checks as not feasible for plain C. Trying further so hard to avoid all the C obstacles is becoming contraproductive. This part has become a sanity-checking one only. It is no longer a pre-requisite for the (planned) siginfo fix. Attaching the two patches (bare rename + the conversion) FYI. They have a regression at least on fork-child-threads.exp. They are based on: Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t http://sourceware.org/ml/gdb-patches/2010-09/msg00078.html From: Pedro Alves Thanks, Jan