We used .br to force a simple line break (with no extra blank line)
after the tag.
Recently, we added .RS/.RS, and .RS comes just after the tag,
and I realized by accident that .RS already forces a simple line break.
Therefore, .br is completely redundant here, and can be removed.
This way we get rid of "raw" *roff requests in this page.
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The previous format/wording for the includes wasn't very clear.
Improve it a bit following Branden's proposal.
It also helps reduce lines of code.
Add a subsection in NOTES explaining the conventions used.
Remove the comment for helping maintain the page,
as the NOTES section is now clear enough.
Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
Reported-by: Dave Martin <Dave.Martin@arm.com>
Reported-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Due to a userspace breakage, commit 1251201c0d34 ("sched/core: Fix
uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic
and code") changed the semantics of sched_getattr(2) when the
userspace struct is smaller than the kernel struct. Now, any
trailing non-zero data in the kernel structure is ignored when
copying to userspace. We also document the original error code
correctly (it was EFBIG not E2BIG) in the BUGS section.
Ref: 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
robustify sched_read_attr() ABI logic and code")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Around the text:
"Feature Test Macro Requirements for glibc..."
replace ".in -4n/.in" with ".RS -4/.RE".
The latter form is more idiomatic use of man macros.
The nroff output is unchanged.
Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Returning its argument without further checks is almost always
wrong for la_version.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The contents of each type are a logical block that is indented as
a block. They are not separate paragraphs that happen to be
indented separately, but a set of continuous paragraphs, all at
the same level, indented as a block from the list entry--the name
of the type--. Therefore, it makes more sense to use block
indentation, represented by .RS/.RE, rather than indenting each
paragraph separately. That way it's also easier to further indent
a separate paragraph inside a block, which happens for example in
the case of float_t & double_t. It's simply much easier now to
use .IP specifically in those cases where you want to indent just
a single paragraph.
Also added an ending separator comment line just after the last
type.
[mtk: minor edits to commit message]
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From the email discussion:
> Hi Alex,
>
> On 9/25/20 9:31 AM, Alejandro Colomar wrote:
>> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
>> ---
>> man2/seccomp.2 | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/man2/seccomp.2 b/man2/seccomp.2
>> index 58033da1c..d6b856c32 100644
>> --- a/man2/seccomp.2
>> +++ b/man2/seccomp.2
>> @@ -1101,7 +1101,7 @@ install_filter(int syscall_nr, int t_arch, int f_errno)
>> };
>>
>> struct sock_fprog prog = {
>> - .len = (unsigned short) (sizeof(filter) / sizeof(filter[0])),
>> + .len = sizeof(filter) / sizeof(filter[0]),
>> .filter = filter,
>> };
>
> I have a small doubt about this change. With the change,
> there are no compilation warnings.
>
> But, if we change the code to something slightly different:
>
> [[
> size_t x = (sizeof(filter) / sizeof(filter[0]));
> struct sock_fprog prog = {
> .len = x,
> .filter = filter,
> };
> ]]
>
> The "cc -Wconversion" gives us the following warning:
>
> warning: conversion from ‘size_t’ {aka ‘long unsigned int’}
> to ‘short unsigned int’ may change value
>
> Presumably we don't get a warning for an assignment of the form
>
> .len = (sizeof(filter) / sizeof(filter[0]))
>
> because the compiler is smart enough to work out that the
> value of the constant expression is within the range of
> "unsigned short".
>
> Your thoughts?
Hi Michael,
I'd say that the cast doesn't fix any problems at all. It silences a
valid warning, and I'd use a pragma for that (to be more explicit about
the intention of silencing a warning) if I do want -Wconversion enabled
(which usually I don't want, because it's too noisy) and I'm sure that
this won't overflow. I'd limit the use casts to only when I *really*
need to.
I guess that if you enable -O3, the warning will vanish again because
the compiler will optimize away 'x' (but I didn't test).
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>