than camelCase or TitleCase.
According to grep and my checked-out source tree, we're currently at
3733379 internal_underscores, 93024 camelCases, and 80831 TitleCases;
so this commit is merely documenting existing practice.
and copyright statements in a comment that begins with /*-. Document
this tradition. A strict adherence to this rule will help resellers
that wish to publish all copyright notices, generated automatically
from the tree. There are too many variant licenses to do it purely
by more complicated pattern matching.
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.
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
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
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
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
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
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.
