Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making code involving syscalls testable in peertracker #5755

Open
jameshiew opened this issue Jan 1, 2025 · 0 comments
Open

Making code involving syscalls testable in peertracker #5755

jameshiew opened this issue Jan 1, 2025 · 0 comments
Labels
help wanted Issues with this label are ready to start work but are in need of someone to do it priority/backlog Issue is approved and in the backlog

Comments

@jameshiew
Copy link
Contributor

  • Version: v1.11.1
  • Platform: N/A
  • Subsystem: Windows syscalls in peertracker

Relates to #5749

Some code which makes direct syscalls is hard to test, e.g. compareObjectHandles which behaves differently on different Windows systems.

func compareObjectHandles(firstHandle, secondHandle windows.Handle) error {
if procCompareObjectHandlesErr != nil {
return procCompareObjectHandlesErr
}
r1, _, e1 := syscall.SyscallN(procCompareObjectHandles.Addr(), uintptr(firstHandle), uintptr(secondHandle))
if r1 == 0 {
return e1
}
return nil
}

One way might be to change these sorts of funcs into methods on a type that allows swapping out syscall.SyscallN and other currently global variables for something that can be overridden at test time, so that surrounding logic can be tested (example in #5749 (comment))

func (s syscaller) compareObjectHandles(firstHandle, secondHandle windows.Handle) error {
	if s.procCompareObjectHandlesErr != nil {
		return s.procCompareObjectHandlesErr
	}
	r1, _, e1 := s.syscallN(*s.procCompareObjectHandlesAddr, uintptr(firstHandle), uintptr(secondHandle))
	if r1 == 0 {
		return e1
	}
	return nil
}
@amartinezfayo amartinezfayo added priority/backlog Issue is approved and in the backlog help wanted Issues with this label are ready to start work but are in need of someone to do it labels Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Issues with this label are ready to start work but are in need of someone to do it priority/backlog Issue is approved and in the backlog
Projects
None yet
Development

No branches or pull requests

2 participants