Axel Dörfler
17049c451a
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11909 a95241bf-73f2-0310-859d-f6bbb57e9c96
33 lines
1.2 KiB
Plaintext
33 lines
1.2 KiB
Plaintext
Things to do to hash.c:
|
|
|
|
Always use curly braces around statements in if/else/while/do/etc.
|
|
that span more than a line -- even around multiline simple statements
|
|
or single-line simple statements preceded by a comment line.
|
|
|
|
Never have lines longer than 80 chars.
|
|
|
|
Remove ^L characters. We don't want/need such crutches.
|
|
Get a good (smart) pagination filter. I have one (a perl script)
|
|
that usually does a decent job for me -- I called it something
|
|
like stdc-print and think I sent you an early verison.
|
|
|
|
I don't like the name `cursor'. I much prefer short names
|
|
like `p' for index variables. I doubt I'll change all of them,
|
|
but thought you should know why some will probably end up changing.
|
|
|
|
#define USE_OBSTACK somewhere
|
|
|
|
Fix this comment. Depending on system and application...
|
|
Mention fragmentation.
|
|
+#if USE_OBSTACK
|
|
+ /* Whenever obstacks are used, it is possible to allocate all overflowed
|
|
+ entries into a single stack, so they all can be freed in a single
|
|
+ operation. It is not clear if the speedup is worth the trouble. */
|
|
+ struct obstack entry_stack;
|
|
+#endif
|
|
|
|
|
|
assert (bucket_limit - bucket == n_buckets) ?
|
|
|
|
remove.c: s/done/successful or ok
|