Details
- Reviewers
emaste jhb markj - Group Reviewers
manpages - Commits
- rG1bffa4416607: ptrace: document ENOMEM
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 38845 Build 35734: arc lint + arc unit
Event Timeline
Note that I'm open to change the return value to EFAULT and documenting that instead; I'm a bit worried about possible breakage in eg debuggers, but, given Mark's explanation of how EFAULT and ENOMEM was squoshed together, it might be safe. So, if you think that's the right way, please tell.
I don't have a strong feeling about it. I agree that it probably doesn't break anything. OTOH we have lots of errnos that don't really make sense, I'm not sure there's much value in fixing this one example. Documenting it is good enough IMO.
| lib/libc/sys/ptrace.2 | ||
|---|---|---|
| 1158 | ||
We can always change both if we decide to use EFAULT instead, so I'm happy to see this go ahead
I like it better if EFAULT is reserved as much as possible to the case where a syscall argument points to an invalid memory location for the calling process, which is undefined behaviour according to POSIX and other standards and often behaves poorly (for example, completing an operation but discarding the result). If the address in the target process passed to PT_READ_I is invalid, this is fully defined and may not be fully avoidable (for example if the traced process is running concurrently).