Holy cow, I wrote a book!
You may hear an old-timer developer use the verb
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.)
The Z (zap) command replaces the current
instruction with a NOP if it is an int 3
(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 TRAP)
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
je short xyz10 ; ignore this one
je short xyz11 ; end of table
jz short xyz10 ; skip - item is hidden
je short gvl10 ; skip - not the magic item
jc short xyz10 ; weird - we shouldn't have two magic items
There were a variety of TRAP macros.
Here we see the one plain vanilla TRAP and a bunch
of fancy traps which trigger only when certain conditions are met.
For example, TRAPc traps if the carry is set.
Here's its definition:
jnc short l
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 TRAP
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.
The 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.
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.