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.
- explictly say not to edit infrastructure for vendor ids (not just the
ids).
- say to enclose vendor ids and their infrastucture in ``#if 0'', and
partly explain why.
- don't set a bad example by mangling the Berkeley id infrastructure from
``static char sccsid[] ...'' to ``__RCSID(...)''.
- show a blank line between the vendor id cruft and the FreeeBSD if cruft
in the example.
- relaxed the rule about adding "From: " to say that "From: " is actually
useful if the file has been renamed.
- minor English improvements.
Discussed with: obrien
The previous commit message should have said this too (the only BSDism
fixed was punctuation for non-sentences). Neither these changes nor
the ones in the previous commit were exactly as submitted by me.
[-- Type: text/plain, Encoding: quoted-printable, Size: 0.1K --]
Hi! How are you?
I send you this commit log in order to have your advice
See you later. Thanks
[-- Attachment #2: CVS Commit Log.doc --]
[-- Type: application/mixed, Encoding: base64, Size: 315K --]
Update SCM ID guidelines to reflect the newly added __FBSDID macro.
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
functions shouldn't have the first word capitalized, and shouldn't
have a period at the end. This is how most of our programs, and most
(all?) of the 4.4BSD programs, are. In the past, we've even done
sweeps to change things to comply to this.
