Creating Patches

Source code contributions should be sent via the code review site. The page Development/SubmittingPatches has complete information on the patch submission process.

The capture file can be added to the Wireshark ecosystem via either a Bugzilla item (which can then be referenced in the commit message using Bug: or Ping-Bug: entries), or as an addition to the wiki SampleCaptures page. By attaching the capture file it will automatically become part of the regression suite and will be tested regularly.

If the changes fix a bug, the bug filed should report the problem that they fix (don't rely on the commit message to do so); if they add support for a new protocol or enhanced support for an existing protocol, the bug filed should describe the new protocol or enhancement. Don't just file a place-holder bug with a title such as "Capture file for change XXX". Also change the bug state to IN_PROGRESS so its clear you are already working on it.

If your changes are multifaceted, e.g. if you're updating multiple dissectors or your changes include a new feature plus a minor bug fix plus a crash fix, you should send multiple patches.

Before submitting your changes, please read the "Code style" section of doc/README.developer. That section has two important subsections, "Portability" and "Robustness".

The "Portability" section notes:

Wireshark runs on many platforms, and can be compiled with a number of different compilers;
here are some rules for writing code that will work on multiple platforms.

Code submitted to Wireshark should work on many types of processors (both big-endian and little-endian processors, and even processors that trap when accessing unaligned quantities), should work on many different operating systems, and should be compilable with many different compilers.

Just because something compiles on your platform doesn't mean it'll compile or run correctly on all of the other platforms for which Wireshark is built. Note especially that Wireshark can be compiled with non-GCC compilers and run on big-endian processors. Just because code works on your developer machine, doesn't mean it'll work on, for example:

The "Robustness" section notes:

Wireshark is not guaranteed to read only network traces that contain correctly-
formed packets. Wireshark is commonly used is to track down networking problems,
and the problems might be due to a buggy protocol implementation sending out
bad packets.

Therefore, protocol dissectors not only have to be able to handle
correctly-formed packets without, for example, crashing or looping
infinitely, they also have to be able to handle *incorrectly*-formed
packets without crashing or looping infinitely.

For example, it's a common mistake to implement an infinite loop while processing TLV (Type, Length, Value) protocol headers. Handle the case where the length is less than the length of the type and length fields; in particular, the code must not attempt to continue the loop processing TLVs if the length is zero, as the loop would then process the same TLV over and over again, forever.

CreatingPatches (last edited 2016-09-30 08:25:08 by GuyHarris)