>> On
>> .Ox ,
>> the
>> .Fn khttp_parse
>> function requires the
>> .Qq stdio proc
>> promises to
>> .Xr pledge 2 .
> As long as it is only a single sentence, that could easily go right
> after the description of the individual function in the DESCRIPTION,
> or alternatively at the end of the DESCRIPTION section.  Custom
> sections are not very nice, in particular when they are so short
> that they hardly justify opening a new section in the first place.
> If you really want to describe multiple different sandboxing
> systems, then i guess ".Sh SANDBOXING" after the DESCRIPTION
> might make sense.  I'm not all that sure that describing any other
> system will be possible without going overboard; they are typically
> much too complicated to be summarized without excessive verbosity.
> But you shall no doubt see whether or not it works...


The only reason I suggest a standalone section is that it's easier to
standardise across manpages.  Saying "it should go after the function"
is too open to interpretation.  Moreover, some functions may have
varying promises depending upon function parameters, which will rapidly
eat into space better left to the functions themselves.

How about .Sh RESOURCES?  This would also fit other systems like
Capsicum.  Though in practice, I think we'll find only pledge documented



Reply via email to