Skip to main content
How Can We Help?
< All Topics
Print

Conflict: DMAC Same-Pointer Safety

Posted
Updated
ByJstar269

Conflict ID: CONFLICT-DMAC-SAMEPTR-001 · Status: OPEN / MEASURED DISAGREEMENT

Question

Is same-pointer sceDmacMemcpy safe, or does the historical warning “Crashes” describe a real contract?

Claims in conflict

  • A — PSPAutotests source comment: a same-pointer call is commented out with a warning equivalent to “Crashes”; there is no expected-output hardware measurement for that disabled call.
  • B — Nakagawa source-owned PSP-3001/6.61-ARK campaign: a controlled same-pointer case returned success and showed no measured corruption for the tested range.

Why they appear incompatible

The old comment may reflect different alignment, size, cache preparation, pointer region, firmware, or test construction. A disabled call is not the same evidence type as a captured scalar result.

Current status

OPEN. Preserve both records; do not declare the historical warning universally wrong or the measured case universally safe.

Resolving experiment

EXP-DMAC-OVERLAP-20260806-A is accepted for the bounded case. EXP-DMAC-BOUNDARY-001 remains planned for a dense size/alignment/cache matrix and exact failure characterization.

Smallest supported conclusion

Same-pointer success/no corruption is measured for the named PSP-3001 case only. Universal same-pointer and overlap semantics remain unknown.

Related finding: FIND-DMAC-OVERLAP-001 · Last reviewed: 2026-08-11.

Current source anchor — Wave 4

The implementation side was refreshed against src/rt/hle.c at main 04daf156; the same-pointer hardware dispute remains unresolved.

Table of Contents