Note that the object size type is, in effect, size_t.

We currently accumulate all of the object data in memory, so we can't
support objects whose size doesn't fit in a size_t; that means the
maximum object size is 2^32-1 bytes on ILP32 platforms, even though we
allow the size to be up to 2^63-1 bytes.

Change-Id: I2b45f2f1a6a4a68c97d34931aea6f5294db41b6e
Reviewed-on: https://code.wireshark.org/review/25174
Reviewed-by: Guy Harris <guy@alum.mit.edu>

diff --git a/epan/export_object.h b/epan/export_object.h
index 1e0e25e17413a2bc6c7069abba9378413028de1e..ddff34a084b0b8e9e316775eeba622e3584d25f2 100644 (file)
--- a/epan/export_object.h
+++ b/epan/export_object.h
@@ -36,7 +36,13 @@ typedef struct _export_object_entry_t {
     gchar *content_type;
     gchar *filename;
     /* We need to store a 64 bit integer to hold a file length
-      (was guint payload_len;) */
+      (was guint payload_len;)
+
+      XXX - we store the entire object in the program's address space,
+      so the *real* maximum object size is size_t; if we were to export
+      objects by going through all of the packets containing data from
+      the object, one packet at a time, and write the object incrementally,
+      we could support objects that don't fit into the address space. */
     gint64 payload_len;
     guint8 *payload_data;
 } export_object_entry_t;