Messages in this thread | | | Date | Tue, 10 Jan 2023 14:57:55 -0500 | Subject | Re: rseq(2) man page | From | Mathieu Desnoyers <> |
| |
On 2023-01-10 14:28, Alejandro Colomar wrote: > > > On 1/10/23 17:54, Mathieu Desnoyers wrote: >
> > [...] > >>>> .BI "int syscall(SYS_rseq, struct rseq *_Nullable " rseq ", uint32_t >>>> " rseq_len \ >>> >>> What's the meaning for NULL? Does it have a valid sentinel meaning, >>> or is it an invalid address? If it's just interpreted as an invalid >>> address (for which from a user-space perspective a crash would be >>> legitimate), then I'd remove _Nullable. >> >> With the flags that are currently implemented (0 or >> RSEQ_FLAG_UNREGISTER), >> the rseq argument is not expected to be legitimately NULL (it would >> return >> -1, errno=EFAULT on registration, or -1, errno=EINVAL on unregister >> attempt). >> >> We may add new flags in the future which would not care about the rseq >> address >> (it could very well be null then). Do you recommend that we only add the >> _Nullable tag when this occurs ? > > Yes; since it's what the user can pass, it makes sense to be as > constrained as possible. If it were some return that the user would > have to inspect, it would make sense to be cautious on the NULL side of > things an use _Nullable preventively, but for an input, non-null is > preferred for now.
OK, updated.
> > > [...] > >> >> Updated version based on your comments pushed into my repo, thanks! > > Cool! I'll have a look.
Thanks! Once you find it to your liking, I plan to sent it as a patch against the man-pages project.
Mathieu
> > Cheers, > > Alex > >> >> Mathieu >> >> >
-- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
| |