Merging upstream version 4.4.0.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 16 insertions, 14 deletions

diff --git a/doc/README.developer b/doc/README.developer
index 6d6ede97..9769dd68 100644
--- a/doc/README.developer
+++ b/doc/README.developer
@@ -165,7 +165,7 @@ functions won't accept a size_t on LLP64:
     unsigned byte_after_greet;
 
     i = strlen(greeting);
-    byte_after_greet = tvb_get_guint8(tvb, i); /* Compiler warning */
+    byte_after_greet = tvb_get_uint8(tvb, i); /* Compiler warning */
 
 Try to use the appropriate data type when you can. When you can't, you
 will have to cast to a compatible data type, e.g.
@@ -175,7 +175,7 @@ will have to cast to a compatible data type, e.g.
     uint8_t byte_after_greet;
 
     i = strlen(greeting);
-    byte_after_greet = tvb_get_guint8(tvb, (int) i); /* OK */
+    byte_after_greet = tvb_get_uint8(tvb, (int) i); /* OK */
 
 or
 
@@ -184,9 +184,9 @@ or
     uint8_t byte_after_greet;
 
     i = (int) strlen(greeting);
-    byte_after_greet = tvb_get_guint8(tvb, i); /* OK */
+    byte_after_greet = tvb_get_uint8(tvb, i); /* OK */
 
-See http://www.unix.org/version2/whatsnew/lp64_wp.html for more
+See https://unix.org/version2/whatsnew/lp64_wp.html for more
 information on the sizes of common types in different data models.
 
 A lot of legacy code still uses GLib types and I/O replacement API. These
@@ -208,14 +208,8 @@ the macros in <inttypes.h>, for example:
     proto_tree_add_uint64_format_value(tree, hf_uint64, tvb, offset, len,
                                        val, "%" PRIu64, val);
 
-For GLib routines, and only those, you can choose whichever format style
-you prefer:
-
-    uint64_t val = UINT64_C(1);
-    char *str1 = g_string_printf("%" G_GUINT64_FORMAT, val);
-    char *str2 = g_string_printf("%" PRIu64, val);
-
-These format macros will be the same modulo any GLib bugs.
+GLib provides the G_GUINT64_FORMAT and G_GINT64_FORMAT specifiers for
+64-bit integral types. You should use PRIu64 and PRId64 instead.
 
 When specifying an integral constant that doesn't fit in 32 bits, don't
 use "LL" at the end of the constant - not all compilers use "LL" for
@@ -725,6 +719,14 @@ should be stored in a 32-bit variable, such as an "int"; if you store it
 in an 8-bit or 16-bit variable, you run the risk of the variable
 overflowing.
 
+If your dissector uses recursion, you must ensure that your code does
+not do so excessively. If there isn't an inherent limit on recursion in
+your dissector, you can can add one using increment_dissection_depth and
+decrement_dissection_depth. Wireshark's CI system uses Clang-tidy to
+check for recursion; you might also need to add suppressions described at
+https://clang.llvm.org/extra/clang-tidy/#suppressing-undesired-diagnostics
+in order to pass CI checks.
+
 sprintf() -> snprintf()
 Prevent yourself from using the sprintf() function, as it does not test the
 length of the given output buffer and might be writing into unintended memory
@@ -772,7 +774,7 @@ Please avoid using tab expansions different from 8 column widths, as not all
 text editors in use by the developers support this. For a detailed discussion
 of tabs, spaces, and indentation, see
 
-    http://www.jwz.org/doc/tabs-vs-spaces.html
+    https://www.jwz.org/doc/tabs-vs-spaces.html
 
 We use EditorConfig (http://editorconfig.org) files to provide formatting
 hints. Most editors and IDEs support EditorConfig, either directly or via
@@ -973,7 +975,7 @@ not toLocal8Bit() or toLatin1().
 
 8. Miscellaneous notes
 
-Each commit in your branch corresponds to a different VCSVERSION string
+Each commit in your branch corresponds to a different VCS_VERSION string
 automatically defined in the header 'vcs_version.h' during the build. If you happen
 to find it convenient to disable this feature it can be done using: