Better English usage.

Submitted by: wollman

Clarify the rule about structure typedefs being discouraged, following
a discussion on src-committers.

Two minor fixes:
o It is the /usr/include files, not the /usr include files.
o Document the practice of converting to the c99 standard uintXX_t
form from the older, but non-standard, BSD-style u_in

Two minor fixes:
o It is the /usr/include files, not the /usr include files.
o Document the practice of converting to the c99 standard uintXX_t
form from the older, but non-standard, BSD-style u_intXX_t. This
has been going on in the tree for a while now, and I've heard other
developers also state that this conversion is happening. Note also
that this is a slow process and should be treated like whitespace
changes.

show more ...

mdoc(7): Use the new feature of the .In macro.

Xref sytle.Makefile(5).

PR: 51183

Revert previous commit which accidentally snuck in with some unrelated
changes.

Reported by: bde

Remove obsolete at_fork() and at_exit() manpages. Curiously, at_exec()
didn't have a manpage.

Reminded by: ru

english(4) police.

mdoc(7) police: scheduled sweep.

Approved by: re

mdoc(7) police:

Revert to using the .Tn POSIX and .Tn ANSI instead of \*[Px] and \*[Ai]
strings; using these strings is unsafe in troff mode, as they include a
change in a font size.

Approved by: re

Further clarifications of the #ifdef/#if/#elif/#endif style information,
largely submitted by bde. Return our exemption of the #ifdef lint
comments since the exemption is intended to handle a partic

Further clarifications of the #ifdef/#if/#elif/#endif style information,
largely submitted by bde. Return our exemption of the #ifdef lint
comments since the exemption is intended to handle a particularly
common current case without mandating change. Improve language and
spelling, and slightly clarify the notions associated specifically
with #elif.

Obtained from: bde

show more ...

Clarify style(9) WRT comments following #endif, #else.

The closing comment is required only for long conditionally defined
code sections, with the exception of lint cases. Attempt to document
also

Clarify style(9) WRT comments following #endif, #else.

The closing comment is required only for long conditionally defined
code sections, with the exception of lint cases. Attempt to document
also the logic for using '!' before the SOMETIMESSOMETHGINGHERE.
The goal of these comments is to make complex cases more
comprehensible, not to require them in all cases. The rules here are
derived from behavior used in 90+% of the kernel source code.

Reviewed by and discussed with: jhb, bde, mike

show more ...

Add a paragraph which should clarify the separation of asterisks
and adjacent tokens in declarations.
The added text was originally a single sentence I wrote and which
was heavily modified and extend

Add a paragraph which should clarify the separation of asterisks
and adjacent tokens in declarations.
The added text was originally a single sentence I wrote and which
was heavily modified and extended by Bruce Evans.

This clarification attempt originates from differing usage of the
'restrict' type-qualifier.
Although various documents documents dicussing the C Programming
Language put a space between an asterisk and the 'restrict' keyword,
including the C99 standard (at least the n869.txt draft) and other
ISO/IEC JTC1/SC22/WG14 documents, the IEEE Std 1003.1-2001 document
does not separate them.

Discussed with: bde
Requested by: tjr
Separation using a single space also liked by: mike

show more ...

Remove a sentence about wrapping macro definitions in bare braces,
which became wrong after using do { } while (0) became recommended.
Move the definition of what braces are to their new first occurr

Remove a sentence about wrapping macro definitions in bare braces,
which became wrong after using do { } while (0) became recommended.
Move the definition of what braces are to their new first occurrence.

Reviewed by: bde

show more ...

Expand a contraction in the text of style(9) for consistency.
Do not touch contractions in comments of code examples because
their usage seems to be justified by space contraints.

Suggest that function prototypes in kernel headers be alphabetical,
unless there's a compelling reason to deviate.

Submitted by: Don Lewis
Suggestion not objected to by: developers@

mdoc(7) police: nit.

Clarify the sizeof(var) rule. This is the result of the consensus in
arch@ between myself, bde and markm. I kept the parts that all of us
agreed to, and omitted some more extensive text that I'd or

Clarify the sizeof(var) rule. This is the result of the consensus in
arch@ between myself, bde and markm. I kept the parts that all of us
agreed to, and omitted some more extensive text that I'd originally
wanted.

show more ...

Clarify version 1.68 to more accurately describe the intent of the change to
try to avoid ambiguous cases in the future.

Wording approved by: julian (early draft), grog, rwatson, wes and maybe other

Clarify version 1.68 to more accurately describe the intent of the change to
try to avoid ambiguous cases in the future.

Wording approved by: julian (early draft), grog, rwatson, wes and maybe other
members of core I'm forgetting.

show more ...

Correct two syntax mistakes.
Fix overflowing right side, so that the && operator fits on the same line.

Remove extraneous newline.

'char *' can be a large entity now (on 64-bit platforms). Thus move it up
to make the example match the text requirements.

mdoc(7) police: markup nit.

The do { } while (0) macro example was missing a space after the 'e'.

Note new status of __P. Don't use it.

Reviewed by: arch@, mckusick (in principle)