[[project @ 2000-04-06 13:37:30 by simonmar]
simonmar**20000406133730
a few updates
] {
hunk ./docs/coding-style.html 4
- Access To The GHC CVS Repository
-
+ GHC Style Guidelines for C code
hunk ./docs/coding-style.html 13
-them are probably misguided. If you disagree with them, feel free to
-modify this document (and make your commit message reasonably informative)
-or mail someone (eg The FP-CVS mailing list or
-reid-alastair@cs.yale.edu).
-
+them are probably misguided. If you disagree with them, feel free to
+modify this document (and make your commit message reasonably
+informative) or mail someone (eg. The GHC mailing list)
hunk ./docs/coding-style.html 29
-
+
hunk ./docs/coding-style.html 34
-
-Indian Hill C Style and Coding Standards.
+ Indian
+Hill C Style and Coding Standards.
hunk ./docs/coding-style.html 38
-
+
hunk ./docs/coding-style.html 41
-
+
hunk ./docs/coding-style.html 44
-
+
hunk ./docs/coding-style.html 47
-
hunk ./docs/coding-style.html 53
-
+
hunk ./docs/coding-style.html 61
- Our POSIX policy: try to write code that only uses POSIX (IEEE
-Std 1003.1) interfaces and APIs. When you include Rts.h,
-POSIX_SOURCE is automatically defined for you before any
-system headers are slurped in, unless you define
-NON_POSIX_SOURCE prior to including Rts.h.
-A good C library will use the POSIX_SOURCE define to
-eliminate non-posix types and function prototypes, so the compiler
-should complain if you venture outside the POSIX spec.
-
-
+
hunk ./docs/coding-style.html 63
+
hunk ./docs/coding-style.html 65
-zero length arrays (useful as the last field of a struct)
-inline annotations on functions (see later)
-Labeled elements in initialisers
-Function attributes (mostly just no_return)
-Macro varargs (actually, we don't use them yet but I'm very tempted)
-Alastair really likes to use C++ style comments - but
- he'll probably regret it later.
-other stuff I've forgotten about...
+zero length arrays (useful as the last field of a struct)
+
+inline annotations on functions (see later)
+
+Labeled elements in initialisers
+
+Function attributes (mostly just no_return and
+unused)
hunk ./docs/coding-style.html 75
-Some of these gcc/ANSI features could be avoided (for example, we
+Some of these gcc/ANSI features could be avoided (for example, we
hunk ./docs/coding-style.html 78
-so we don't try with the others.
+so we don't try with the others.
hunk ./docs/coding-style.html 80
-
+Most of these features are actually part of the new C9X standard,
+so we hope to have mostly conformant code at some point in the future.
+
+
+Please don't use C++ style comments, they aren't standard C.
+
+
hunk ./docs/coding-style.html 89
-
+ Our POSIX policy: try to write code that only uses POSIX (IEEE
+Std 1003.1) interfaces and APIs. When you include Rts.h,
+POSIX_SOURCE is automatically defined for you before any
+system headers are slurped in, unless you define
+NON_POSIX_SOURCE prior to including Rts.h.
+A good C library will use the POSIX_SOURCE define to
+eliminate non-posix types and function prototypes, so the compiler
+should complain if you venture outside the POSIX spec.
+
+
hunk ./docs/coding-style.html 117
-
+
hunk ./docs/coding-style.html 123
-
+
hunk ./docs/coding-style.html 127
-within GHC we assume they are 32 bits. (I'm not sure if this is a
-good idea - ADR)
+within GHC we assume they are 32 bits (do we? --SDM).
hunk ./docs/coding-style.html 129
-
+
hunk ./docs/coding-style.html 159
-
+
hunk ./docs/coding-style.html 199
-
+
hunk ./docs/coding-style.html 205
-
+
hunk ./docs/coding-style.html 211
-
+
hunk ./docs/coding-style.html 215
-
+
hunk ./docs/coding-style.html 230
- Use #warning or #error whenever you write a piece of incomplete/broken code.
+ Use #warning or #error whenever you write a piece of incomplete/broken code.
hunk ./docs/coding-style.html 232
- When testing, try to make infrequent things happen often.
+ When testing, try to make infrequent things happen often.
hunk ./docs/coding-style.html 242
-Important: Put "redundant" braces or parens in your code.
+Important: Put "redundant" braces or parens in your code.
hunk ./docs/coding-style.html 250
-
+
hunk ./docs/coding-style.html 255
-
+
hunk ./docs/coding-style.html 266
-
+
hunk ./docs/coding-style.html 326
-
+
hunk ./docs/coding-style.html 334
-
+
hunk ./docs/coding-style.html 340
-Inline functions get the naming issue right. E.g. they
+Inline functions get the naming issue right. E.g. they
hunk ./docs/coding-style.html 344
- Inline functions have call-by-value semantics whereas macros
+ Inline functions have call-by-value semantics whereas macros
hunk ./docs/coding-style.html 348
- You can use inline functions from inside gdb if you compile with
+ You can use inline functions from inside gdb if you compile with
hunk ./docs/coding-style.html 364
-
+
hunk ./docs/coding-style.html 367
-
+
hunk ./docs/coding-style.html 370
-
+
hunk ./docs/coding-style.html 414
-
+
hunk ./docs/coding-style.html 429
-but Alastair prefers to split the declarations.
+but it is preferrable to split the declarations.
hunk ./docs/coding-style.html 431
-
+
hunk ./docs/coding-style.html 481
-ToDo: at the time of writing, we still use the former.
-
-
-Alastair likes to use stgCast instead of C syntax. He claims
-it's easier to write and easier to grep for. YMMV.
-
-#define stgCast(ty,e) ((ty)(e))
-
hunk ./docs/coding-style.html 482
- Please keep to 80 columns: the line has to be drawn somewhere,
+ Please keep to 80 columns: the line has to be drawn somewhere,
hunk ./docs/coding-style.html 487
- We don't care too much about your indentation style but, if
+ We don't care too much about your indentation style but, if
hunk ./docs/coding-style.html 489
-rest of the function (or file).
+rest of the function (or file). If you're writing new code, a
+tab width of 4 is preferred.
hunk ./docs/coding-style.html 522
-
+
}