osmith
/
wireshark
forked from osmocom/wireshark
1
0
Fork 0
Code Pull Requests Releases Wiki Activity

Add some more notes on What Not To Do when writing code for Ethereal, so 

as not to end up with, for example, code that works fine with GCC but
fails to compile with other compilers.

svn path=/trunk/; revision=3758
This commit is contained in:
Guy Harris 2001-07-20 23:38:30 +00:00
parent 45510255a7
commit 6e2d931517
1 changed files with 31 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
doc/README.developer
View File

@ -1,4 +1,4 @@
$Id: README.developer,v 1.31 2001/07/20 09:55:08 guy Exp $
$Id: README.developer,v 1.32 2001/07/20 23:38:30 guy Exp $
This file is a HOWTO for Ethereal developers. It describes how to start coding
a Ethereal protocol dissector and the use some of the important functions and
@ -18,12 +18,35 @@ add to the protocol tree, and work with registered header fields.
1.1 Code style.
1.1.1 Comments.
1.1.1 Portability.
Don't use C++-style comments (comments beginning with "//" and running to the
end of the line); Ethereal's dissectors are written in C, and thus run through C
rather than C++ compilers, and not all C compilers support C++-style comments
(GCC does, but IBM's C compiler for AIX, for example, doesn't do so by default).
Ethereal 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.
Don't use C++-style comments (comments beginning with "//" and running
to the end of the line); Ethereal's dissectors are written in C, and
thus run through C rather than C++ compilers, and not all C compilers
support C++-style comments (GCC does, but IBM's C compiler for AIX, for
example, doesn't do so by default).
Don't use zero-length arrays; not all compilers support them. If an
array would have no members, just leave it out.
Don't use "inline"; not all compilers support it. If you want to have a
function be an inline function if the compiler supports it, use
G_INLINE_FUNC, which is declared by <glib.h>. This may not work with
functions declared in header files; if it doesn't work, don't declare
the function in a header file, even if this requires that you not make
it inline on any platform.
Don't use "long long"; use "gint64" or "guint64", and only do so if
G_HAVE_GINT64 is defined. Make sure your code works even if
G_HAVE_GINT64 isn't defined, even if that means treating 64-bit integral
data types as opaque arrays of bytes on platforms where it's not
defined. Also, don't assume you can use "%lld", "%llu", "%llx", or
"%llo" to print 64-bit integral data types - not all platforms support
"%ll" for printing them.
1.1.2 Name convention.
@ -62,7 +85,7 @@ code inside
is needed only if you are using the "snprintf()" function.
The "$Id: README.developer,v 1.31 2001/07/20 09:55:08 guy Exp $"
The "$Id: README.developer,v 1.32 2001/07/20 23:38:30 guy Exp $"
in the comment will be updated by CVS when the file is
checked in; it will allow the RCS "ident" command to report which
version of the file is currently checked out.
@ -72,7 +95,7 @@ version of the file is currently checked out.
* Routines for PROTONAME dissection
* Copyright 2000, YOUR_NAME <YOUR_EMAIL_ADDRESS>
*
* $Id: README.developer,v 1.31 2001/07/20 09:55:08 guy Exp $
* $Id: README.developer,v 1.32 2001/07/20 23:38:30 guy Exp $
*
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com>