You may hear an old-timer developer use the verb zap.
That proposed fix will work. Until everybody gets the fix, they can just zap the assert.
The verb to zap means to replace a breakpoint instruction with an appropriate number of NOP instructions (effectively ignoring it).
The name comes from the old Windows 2.x kernel debugger.
(Actually, it may be even older, but that's as far back as I
was able to trace it.)
Z (zap) command replaces the current
instruction with a NOP if it is an
(the x86 single-byte breakpoint instruction),
or replaced the previous instruction with NOPs if it is an
(the x86 two-byte breakpoint instruction).
This operation was quite common back in the days when
lots of code was written in assembly language.
A technique used by some teams was to insert
a hard-coded breakpoint (called a
into every code path of a function.
Here's an example (with comments and other identifying characteristics
removed and new ones made up):
xyz8: mov bl,[eax].xyz_State cmp bl,XYZSTATE_IGNORE TRAPe je short xyz10 ; ignore this one or bl,bl TRAPe je short xyz11 ; end of table mov bh,[eax].xyz_Flags test bh,XYZFLAGS_HIDDEN TRAPz jz short xyz10 ; skip - item is hidden test bh,XYZFLAGS_MAGIC TRAPe je short gvl10 ; skip - not the magic item TRAP bts [esi].alt_flags,ALTFLAGS_SEENMAGIC TRAPc jc short xyz10 ; weird - we shouldn't have two magic items
There were a variety of
Here we see the one plain vanilla
TRAP and a bunch
of fancy traps which trigger only when certain conditions are met.
TRAPc traps if the carry is set.
Here's its definition:
TRAPc MACRO local l jnc short l int 3 l: ENDM
Hardly rocket science.
When you became the person to trigger a particular code path for
the first time,
you would trigger the trap, and you either stepped through
the code yourself or (if you weren't familiar with the code)
contacted the author of the code to verify that the code
successfully handled this "never seen before" case.
When sufficiently satisfied that a code path operated as expected,
the developer removed the corresponding
from the source code.
Of course, most
TRAPs are removed before the code
gets checked in, but the ones related to error handling or
recovering from data corruption
tend to remain
(such as here, where we inserted a
TRAP when we
encounter two magic items, which is theoretically impossible).
When you trigger one trap,
you usually trigger it a lot,
and you usually trigger a lot of related traps as well.
Z command was quite handy at neutering each
one after you checked that everything was working.
You zapped the trap.
That's why old-timers refer to patching out a hard-coded breakpoint as zapping, even though the zap command hasn't existed for over a decade.
Update: As far as I can tell, the earlier uses of the word zap referred to patching binaries, not for removing hard-coded breakpoints after they stopped in the debugger.