CodingStyle

CodingStyle

@@ -0,0 +1,89 @@
+If you start a new file, you get to choose the style.
+If you change an existing file, follow the existing style.
+
+Hard tabs are OK, as long as you consider the tab stops to
+be every 8 characters. You can also use 2, 3, or 4 spaces.
+
+Spaces within a line don't matter much, and won't be
+considered part of the style. Just make it readable:
+
+if(x){            // OK
+if( x ){           // OK
+if (x) {            // OK
+if(x==y && a==b){     // OK
+if(x == y && a == b){ // poor
+if(x==y&&a==b){       // poor
+
+This is evil:
+
+szWinStallman
+FoulCodingStyle (int iInsanity)
+  {
+     if (iInsanity)
+       {
+          GoHackEmacs () ;
+       }
+          else
+       {
+          SeekHelpForYourLisp () ;
+       }
+  }
+
+
+Curly braces belong at the end of a line. If you must, go ahead
+and make function bodies an exception to that rule. (as Linus does)
+
+Big fprintf() calls and similar go like this:
+
+fprintf(fd, "%d %d %d %d %d %d\n",
+  sdfsdf_sdfsdf + sdfs_iii,     // not an example of good names!
+  iijjij,
+  kjfkkj_sdfssss_sfff,
+  sdflkjfdskj + sdf - sfds,
+  jksss,
+  sfssss + wwwwfwfw
+);
+
+Command-line parsers need to be bomb-proof. It is not acceptable
+to crash due to a messed up command-line. For an option "-x" that
+takes an argument, accept both "-x arg" and "-xarg". Remember to
+support "--" and "--version".
+
+Be extremely careful when handling data from other users.
+For example, it is a security hole if /proc/123/cmdline can
+overflow an array. It is often a security hole if you allow
+non-ASCII characters to be printed. Assuming the console is
+not in UTF-8 mode, all of these are bad: "\b\e\f\n\r\t\v\x9b".
+(the "\x9b" is valid in UTF-8 mode, but equivalent to "\e["
+when not in UTF-8 mode -- which gives control of terminal
+settings)
+
+Remember that a read() may return early, with partial data
+or with -1 and errno set to EINTR. You then must try again.
+
+char: may be signed or unsigned by default
+int: always 32-bit
+long long: always 64-bit
+long: same size as a pointer, either 32-bit or 64-bit
+
+Functions used in just one file must be marked static.
+Use the "const" and "restrict" keywords wherever you can.
+
+Put main() at the bottom of a file so you don't need all
+those ugly forward declarations.
+
+Avoid the strcat() function. It is slow. For some odd
+reason, snprintf() is faster than sprintf().
+
+Reuse memory allocations when you can. When using realloc(),
+do your increments by more than one. 25% is a nice amount.
+
+Avoid compile-time choices. They make documentation difficult,
+and they are not friendly to binary distribution.
+
+Write programs that can handle a million processes without
+getting hopelessly slow. Allow for /proc/123/cmdline to
+be at least 128 kB.
+
+The LGPL license is strongly preferred. This allows use of
+the code in the library.

NEWS

@@ -1,3 +1,6 @@
+procps-3.1.9 --> procps-3.1.10
+
+
 procps-3.1.8 --> procps-3.1.9
 
 memory sizes fixed for 64-bit w/ gcc 3.x      #194376 #191933