Covered the event flags get refusal of a request for no flags

2026-09-20T04:58:07Z

The get service refuses to suspend a caller when the preemption lockout is raised or when the request asks for no flags at all. The first arm is driven by the suite's own preempt-disable safeguard; the second had no caller anywhere in the suite, so one of the site's four outcomes was never taken. Measured rather than inferred: the tracefiles put the uncovered outcome on the zero-request operand in all eight configurations. A new test asks the group for no flags under each of the four get options, with a wait option, and then confirms that the flag it raised beforehand is still set. The error checking shell places no constraint on the requested flags, so the published service reaches the refusal with nothing forced. A request for no flags can never be satisfied — an OR request finds none of the flags it asked for present, and an AND request has its empty result rejected for not matching the empty set it asked for — so a caller that suspended on one would never be resumed, which is what the check prevents. The site reads four of four on the union basis, which is the only genuine control logic this group had. 123/123 tests pass in each of the eight configurations, and the new test passes fifty standalone repeats in every one of them. Assisted-by: Claude Code (Opus 5)

threadx.git/test/smp/regression/threadx_event_flag_zero_request_test.c, branch v6.4.1_cert

Covered the event flags get refusal of a request for no flags