Difficulty: Hard · Puzzle 6 of 6 · Topic: Handle and Copy Puzzles
A class has nested handle members but only uses field macros for scalars. Why can `clone()` still leak aliasing?
class hdr extends uvm_object;
`uvm_object_utils(hdr)
int opcode;
function new(string name="hdr"); super.new(name); endfunction
endclass
class tr extends uvm_sequence_item;
`uvm_object_utils_begin(tr)
`uvm_field_int(addr, UVM_DEFAULT)
`uvm_object_utils_end
int addr;
hdr h;
function new(string name="tr");
super.new(name);
h = hdr::type_id::create("h");
endfunction
// no do_copy override
endclassWhich members are actually registered to automation macros?
1) `clone()` relies on `copy()` and field automation unless overridden.
2) Only `addr` is registered; nested handle `h` is not covered, so automation does not deep-copy it.
3) Depending on implementation defaults, `h` may remain shared or stale, causing aliasing bugs.
4) Register `h` with `uvm_field_object` or write explicit `do_copy/do_compare` for deterministic ownership.Answer: Because nested handle `h` is not part of copy automation and no custom `do_copy` exists, clone semantics are incomplete and can leave shared/stale nested state.
Many candidates trust `clone()` blindly without auditing which fields are actually copied.
Would you prefer field macros or hand-written copy for high-performance scoreboards, and why?