Re: [PATCH] arm reversible : <phase_2_complete>

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Petr" == Petr HluzÃn <petr.hluzin@gmail.com> writes:

Petr> How strong is the "can't happen" requirement? Is programmer required
Petr> to prove the assertion cannot be triggered? The difficulty in general
Petr> case would be equivalent to proving a code is bug-free - i.e. it is
Petr> impossible. At my job we try to verify an assumption until we have a
Petr> sort-of-proof or the search becomes difficult and no clue/indication
Petr> to the contrary has been found yet.
Petr> I am asking because GDB code contains surprisingly few assertions.

I don't think there is a hard-and-fast rule in gdb.  I am not completely
sure though.

I think in gdb it is best to error instead of assert if there is any
doubt.  That's because I think when people turn to gdb they are already
a bit frustrated, and then if gdb itself fails, this is extremely
irritating.  That's certainly been the case for me in the past.

I realize you can sort of recover from internal_error (and hence
assertions).  But my impression is that internal_error is treated like
"not an exception-thrower" in gdb, leading to cleanup problems and the
like.

Petr> Anyway, the patch had used assertions correctly because expression
Petr> `bits (X, 21, 24)' yields value in range 0..15 for any value of X - no
Petr> matter how bogus X value. Yes, all 2^32 values map to 0..15. The
Petr> assertions satisfy the guideline. (This is not even the hard-to-prove
Petr> case I was speculating above.)

Yeah, my review was wrong here.

Tom