add a small section, that code should be warning free
authorulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Sat, 31 Mar 2007 15:32:06 +0000 (15:32 +0000)
committerulfl <ulfl@f5534014-38df-0310-8fa8-9805f1628bb7>
Sat, 31 Mar 2007 15:32:06 +0000 (15:32 +0000)
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@21291 f5534014-38df-0310-8fa8-9805f1628bb7

doc/README.developer

index bcd06b1b69edac4015e64601fdf01902cafe52e7..a9a9203c3bfba1251cb38837770ca7d2000473ee 100644 (file)
@@ -579,7 +579,7 @@ Wireshark uses the underscore_convention rather than the InterCapConvention for
 function names, so new code should probably use underscores rather than
 intercaps for functions and variable names. This is especially important if you
 are writing code that will be called from outside your code.  We are just
-trying to keep things consistent for other users.
+trying to keep things consistent for other developers.
 
 1.1.5 White space convention.
 
@@ -602,6 +602,15 @@ utility on an existing file.  If you run across wildly varying
 indentation styles within the same file, it might be helpful to send a
 note to wireshark-dev for guidance.
 
+1.1.6 Compiler warnings
+
+You should write code that is free of compiler warnings. Such warnings will 
+often indicate questionable code and sometimes even real bugs, so it's best 
+to avoid warnings at all. 
+
+The compiler flags in the Makefiles are set to "treat warnings as errors", 
+so your code won't even compile when warnings occur.
+
 1.2 Skeleton code.
 
 Wireshark requires certain things when setting up a protocol dissector.