This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] manual: Document mprotect and introduce section on memory protection


On 11/19/2017 02:27 AM, Florian Weimer wrote:

>>>>> +@var{protection} is a combination of the @code{PROT_*} flags
>>>>> described
>>>>> +above.
>>>>> +
>>>>
>>>> The return values of the function are also missing:
>>>>
>>>> "@code{mprotect} returns @code{0} on success or @code{-1} on error."
>>>
>>> Do we use @code{-1} or @math{-1}?  Existing practice is incosistent.
>>
>> @math is for mathematical expressions, and the Texinfo manual says: "In
>> essence, @math switches into plain TeX math mode." [1]  While the
>> Texinfo manual never explicitly states return values should be formatted
>> with @code, consider the example they use for how @code looks when it's
>> rendered: "The function returns @code{nil}." [2]
> 
> $nil$ is a product of the variables $n$, $i$, $l$, so it's clearly
> different.  In LaTeX, inside a mathematical expression, you would use
> something like $\mathrm{nil}$, or more likely, a special symbol.

I usually opt for @code because of the function context, but have always
held reservations because it is referring to an abstract value.  I think
you have a good argument for @math, if I'm understanding your point.

There are some interesting partially-numeric use cases for return
values, though.  mbrtowc is a good example.

Rical


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]