* coding-style: Assume ANSI C '89. Use krb5int_ for internal names

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@12918 dc483132-0cff-0310-8789-dd5450dbe970

diff --git a/doc/ChangeLog b/doc/ChangeLog
index 16962af45d10f040e18aabc40de4d3d4250656ea..e302e05b8127d3fd4595840713d70811fcf763ba 100644 (file)
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,8 @@
+2001-01-19  Ken Raeburn  <raeburn@mit.edu>
+
+       * coding-style: Assume ANSI C '89.  Use krb5int_ for internal
+       names.
+
 2000-07-12  Tom Yu  <tlyu@mit.edu>
 
        * coding-style: Update after some discussion.  Add sections

diff --git a/doc/coding-style b/doc/coding-style
index 3e1d233d01f52133d2757bef9285a6234d61cb39..524c8a61e321979da4bbb193e9c7c70cf022df29 100644 (file)
--- a/doc/coding-style
+++ b/doc/coding-style
@@ -136,6 +136,10 @@ In general, do not parenthesize the argument of "return".
 Coding practices for C
 ----------------------
 
+Assume, for most purposes, working ANSI/ISO C ('89, not '99) support,
+both for internal use and for applications compiling against Kerberos
+header files and libraries.  Some exceptions are noted below.
+
 Do not use assignments as truth values.  Rather than this:
 
        /* bad style */
@@ -318,15 +322,10 @@ required to return int by the standard.  If a function is not supposed
 to return a value, declare it as returning void rather than omitting
 the return type, which will default the return type to int.
 
-When using K&R style function definitions, declare all the argument
-types, even those that are int. [XXX it is debatable whether to
-require K&R style function definitions for all except stdarg
-functions]
-
-For krb5 code, we have been making the assumption that an ANSI
-compiler is required to compile the distribution, but not to link
-against it.  For this, and other reasons, the use of narrow types in
-API functions is highly discouraged.
+Try to use ANSI C prototype-style function definitions in preference
+to K&R style definitions.  When using K&R style function definitions,
+declare all the argument types, even those that are int, but beware of
+any narrow types in the argument list.
 
 Do not declare variables in an inner scope, e.g. inside the compound
 substatement of an if statement, unless the complexity of the code
@@ -418,11 +417,11 @@ the application, pick another (related) prefix to use for the internal
 globals.  This applies to typedef names, tag names, and preprocessor
 identifiers as well.
 
-For the krb5 library, the prefix for public global symbols is
-"krb5_".  It is a matter of debate whether to use "krb5__" or
-"krb5int_" as a prefix for library internal globals.  There are
-admittedly a number of places where we leak thing into the namespace;
-we should try to fix these.
+For the krb5 library, the prefix for public global symbols is "krb5_".
+Use "krb5int_" as a prefix for library internal globals.  Avoid using
+"__" in symbol names, as it may confuse C++ implementations.  There
+are admittedly a number of places where we leak thing into the
+namespace; we should try to fix these.
 
 Header files should also not leak symbols.  Usually using the upcased
 version of the prefix you've picked will suffice, e.g. "KRB5_" as a