should be working, should be

git-svn-id: https://svn.vegaa.systems/svn/vega-Vega/trunk@7 a8a8aea2-181d-ee11-89e8-15fd0e089fc4

2 files changed, 206 insertions, 0 deletions

diff --git a/share/misc/style b/share/misc/style
new file mode 100644
index 0000000..03bcc72
--- /dev/null
+++ b/share/misc/style
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2023 Ian Marco Moffett and the VegaOS team.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ *    this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of VegaOS nor the names of its
+ *    contributors may be used to endorse or promote products derived from
+ *    this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <sys/cdefs.h>
+
+/*
+ * Vim config in share/misc/vimrc
+ */
+
+/*
+ * Metadata goes in *.c files
+ */
+__KERNEL_META("$Vega$: style.c, Ian Marco Moffett, "
+              "Vega style guide");
+/*
+ * VERY important single-line comments look like this.
+ */
+
+/* Most single-line comments look like this. */
+
+/*
+ * Multi-line comments look like this.  Make them real sentences.  Fill
+ * them so they look like real paragraphs.
+ */
+
+/*
+ * Attempt to wrap lines longer than 80 characters appropriately.
+ * Refer to the examples below for more information.
+ */
+
+/*
+ * EXAMPLE HEADER FILE.
+ * A header file should protect itself against
+ * multiple inclusion.
+ */
+ #ifndef _SYS_FOO_H_
+ #define _SYS_FOO_H_
+
+ 
+/*
+ * extern declarations must only appear in header files, not in .c
+ * files, so the same declaration is used by the .c file defining it
+ * and the .c file using it, giving the compiler the opportunity to
+ * detect type errors.
+ *
+ * extern function declarations should not use the extern keyword,
+ * which is unnecessary.
+ *
+ * Exception: A subroutine written in assembly in an adjacent .S file,
+ * which is used only in one .c file, may be declared in the .c file.
+ */
+extern int g_foo;
+
+int funnify(const char *s);
+
+#endif     /* !_SYS_FOO_H_ */
+
+/*
+ * END OF EXAMPLE HEADER FILE
+ */
+
+/*
+ * If a header file requires structures, defines, typedefs, etc. from
+ * another header file it should include that header file and not depend
+ * on the including file for that header including both.  If there are
+ * exceptions to this for specific headers it should be clearly documented
+ * in the headers and, if appropriate, the documentation.  Nothing in this
+ * rule should suggest relaxation of the multiple inclusion rule and the
+ * application programmer should be free to include both regardless.
+ */
+
+/*
+ * Kernel include files come first.
+ */
+#include <sys/param.h>      /* <sys/param.h> first, */
+#include <sys/types.h>      /*   <sys/types.h> next, */
+#include <sys/ioctl.h>      /*   and then the rest, */
+#include <sys/socket.h>     /*   sorted lexicographically.  */
+#include <sys/stat.h>
+#include <sys/wait.h>
+
+
+/*
+ * Macros are capitalized, parenthesized, and should avoid side-effects.
+ * If they are an inline expansion of a function, the function is defined
+ * all in lowercase, the macro has the same name all in uppercase.
+ * If the macro is an expression, wrap the expression in parentheses.
+ * If the macro is more than a single statement, use ``do { ... } while (0)''
+ * or ``do { ... } while (false)'', so that a trailing semicolon works.
+ * Right-justify the backslashes; it makes it easier to read.
+ */
+#define MACRO(v, w, x, y)               \
+    do {                                \
+        v = (x) + (y);                  \
+        w = (y) + 2;                    \
+    } while (0)
+
+};
+
+/*
+ * Sometimes we want a macro to be conditionally defined for debugging
+ * and expand to nothing (but still as statement) when we are not debugging:
+ */
+#if defined(FOO_DEBUG)
+#define DPRINTF(...) KDEBUG(__VA_ARGS__)
+#else
+#define DPRINTF(...) __nothing
+#endif  /* defined(FOO_DEBUG) */
+
+/*
+ * The function type must be declared on a line by itself
+ * preceding the function.
+ */
+static char *
+function(int fooy)
+{
+	/*
+	 * When declaring variables in functions, multiple variables per line
+	 * are okay. If a line overflows reuse the type keyword.
+	 *
+	 * Function prototypes and external data declarations should go in a
+	 * suitable include file.
+	 *
+	 * Avoid initializing variables in the declarations; move
+	 * declarations next to their first use, and initialize
+	 * opportunistically. This avoids over-initialization and
+	 * accidental bugs caused by declaration reordering.
+	 */
+     int foo, bar;
+
+     foo = 0;
+     bar = 0;
+	/*
+	 * Casts and sizeof's are not followed by a space.
+	 *
+	 * We parenthesize sizeof expressions to clarify their precedence:
+	 *
+	 * 	sizeof(e) + 4
+	 * not:
+	 *	sizeof e + 4
+	 *
+	 * We don't put a space before the parenthesis so that it looks like
+	 * a function call. We always parenthesize the sizeof expression for
+	 * consistency.
+	 *
+	 * On the other hand, we don't parenthesize the return statement
+	 * because there is never a precedence ambiguity situation (it is
+	 * a single statement).
+	 *
+	 * NULL is any pointer type, and doesn't need to be cast, so use
+	 * NULL instead of (struct foo *)0 or (struct foo *)NULL.  Also,
+	 * test pointers against NULL because it indicates the type of the
+	 * expression to the user. I.e. use:
+	 *
+	 *	(p = f()) == NULL
+	 * not:
+	 *	!(p = f())
+	 *
+	 * Don't use `!' for tests unless it's a boolean.
+	 * E.g. use "if (*p == '\0')", not "if (!*p)".
+	 *
+	 * Routines returning ``void *'' should not have their return
+	 * values cast to more specific pointer types.
+	 *
+	 * Prefer sizeof(*var) over sizeof(type) because if type changes,
+	 * the change needs to be done in one place.
+	 *
+	 * Prefer EXIT_FAILURE instead of random error codes.
+	 */
+
+	/* No parentheses are needed around the return value. */
+	return 0;
+}
diff --git a/share/misc/vimrc b/share/misc/vimrc
new file mode 100644
index 0000000..f8a2ba8
--- /dev/null
+++ b/share/misc/vimrc
@@ -0,0 +1,7 @@
+set cindent
+set cinoptions=(4200,u4200,+0.5s,*500,:0,t0,U4200
+set indentexpr=IgnoreParenIndent()
+set indentkeys=0{,0},0),:,0#,!^F,o,O,e
+set sw=4 ts=4
+set softtabstop=4
+set expandtab