Re: rseq(2) man page

[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