aboutsummaryrefslogtreecommitdiffstats
path: root/epan/proto.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-25Fix lots of spellingsMartin Mathieson1-1/+1
2024-02-22Fix some spelling errorsMartin Mathieson1-1/+1
2024-02-15epan: Fix copy-paste errorJohn Thacker1-1/+1
Coverity CID 1592124
2024-02-14columns: Allow any field expression syntax to be used in columnsJohn Thacker1-4/+127
Allow anything that can be used in a display filter to be used in columns (with the exception that field references don't work without a notion of a currently selected frame): display filter functions, slices, arithmetic calculations, logical tests, raw byte addressing, the layer modifier, display filter macros, etc., alone or in combination. Show the results and generate filters. Note that "resolved" values are not yet supported. They make conceptual sense for some expressions (e.g., if the layer modifier only is used) but not for others. Perhaps resolution could be done as a final step in the filter before returning values. It would also be useful to be able to get the expected return type of an expression, so that the functions for right justifying a column or sorting numerically could work. Right now the results are treated as strings even if the return field values are numeric. Multifield columns (i.e., concatenation of field values) are currently implemented using the OR operator.For backwards compability, continue to support that. When a true logical OR would give a different result, surround the expression in parentheses, which the multifield columns did not previously support (due to the regex used instead of full filter grammar parsing.) Perhaps in the future we should introduce a separate operator for concatenation, possibly only used in column definitions and nowhere else. Update release notes. Fix #7752. Fix #10154. Fix #15990. Fix #18588. Fix #19076. Related to #16181 - it's now possibly to define new display filter functions so that is essentially solved, though I suppose there's always room for more built-in functions.
2024-02-12epan: custom column FT_NONE and FT_PROTOCOL check marksJohn Thacker1-3/+3
Fix a (cut and paste?) error adding check marks to the wrong expression for FT_NONE and FT_PROTOCOL in resolved vs unresolved
2024-02-06Fix some more spelling errorsMartin Mathieson1-2/+2
2024-02-01epan: Pass in a 64 bit integer to proto_tree_add_boolean functionsJohn Thacker1-48/+7
Some of the functions in proto.c when handling a FT_BOOLEAN field allow it to be part of a 64 bit unsigned integer with a 64 bit bitmask. Other functions do not. Some of the functions start out allowing a 64 bit bitmask and then switch to casting the value to a 32 bit unsigned integer (but others don't.) Consistently allow a boolean to be extracted using a 64 bit bitmask by changing the various proto_tree_add_boolean functions to allow a 64 bit unsigned integer value parameter. There was only one function adding a boolean that already took a 64 bit value, proto_tree_add_boolean_bits_format_value64, a counterpart of proto_tree_add_boolean_bits_format_value. It was never used anywhere and not WS_DLL_PUBLIC, so it is safe to remove in favor of having the latter take a uint64_t. Note that _proto_tree_add_bits_format_value, as a comment says: "does not receive an actual value but a dimensionless pointer to that value. For this reason, the type of the header field is examined in order to determine what kind of value we should read from this address. The caller of this function must make sure that for the specific header field type the address of a compatible value is provided." Both proto_tree_add_boolean_bits_format_value and proto_tree_add_boolean_bits_format_value64 called that function, one passing a pointer to a guint32 as a void*, the other passing a pointer to a guint64. In both cases it was cast to a guint32*, which was less than ideal in the value64 case. Fix that. This is related to #19552, as it is necessary in order to add support for passing a UInt64 value to a boolean field (as oppposed to extracting it directly from the tvb.)
2024-01-30epan: Don't fake child nodes of visible proto itemsJohn Thacker1-15/+25
If a field_info is visible, we don't fake the representation and allow the representation and length to be set after construction. Therefore, when trying to add a child item to a tree item that has a visible field_info, we can't fake the child node and return the current tree node. If we do, we can't distinguish between an attempt to set the length or representation of the current tree item, and an attempt to set the length or representation of the faked child (or its descendent) because they'd both have the same node. Since we need the lengths of protocol items for the proto hierarchy stats (and many protocols are added with length "to the end of the frame" and then fixed later), if we're not faking protocols, don't set a protocol field info to hidden even if the tree is not visible. There are probably still some issues related to the use of proto_item_get_parent[_nth]. We might have to avoid faking nodes for any lineal descendent of an item whose representation we need. Related to #19619 (fixes some handling of MATE ranges), related to #19573 (fixes getting the representation of certain items that are also subtrees and have children that set their representation), and fixes the Protocol Hierarchy stats issue in #17877.
2024-01-22epan: Use an ellipsis to indicate truncated fieldsGerald Combs1-2/+2
Show truncated fields as "Field name […]: data" instead of "Field name [truncated]: data". This lets us show a few more characters of data.
2024-01-11tshark: Fake unused proto items when -e is givenJohn Thacker1-13/+49
Add a new hfi reference type for when we're printing items, that supersedes direct reference - in addition to ensuring that we don't fake an item, it also defaults the item to visible (doesn't mark it as hidden when the tree isn't visible), so that the string representation isn't faked either for fields that have non-default formats. Use it when fields are specified with -e; instead of setting the entire tree as visible, only mark visible the items that we want to print. This speeds up tshark -e output with all the -T options that support it, sometimes by 2 to 4 times. Part of #19573
2023-12-20epan: Add as much of a text-only subtree length as we canJohn Thacker1-5/+5
proto_tree_add_text_valist_internal calls proto_tree_add_text_node, which calls proto_tree_add_pi() with the internal hf_text_only FT_NONE item, which calls get_hfi_length which does the adjustment of the length to be either everything in the tvbuff (if length is -1), or the minimum of what's in the tvbuff and the length (if length is not -1 and we have the tvbuff.) This proto_tree_add_text_valist_internal doesn't need to do its own version of the check. In particular, this means when adding a text-only subtree with a tvb truncated with capture, the subtree will be added truncated and the exception will be thrown when retrieving the first unavailable item, instead of throwing the exception immediately. This is the behavior already done when adding FT_PROTOCOL and FT_NONE items via other methods. Related to #19544
2023-12-09nflog: time stamps are in seconds/microseconds, not seconds/nanoseconds.Guy Harris1-6/+38
See 1. https://www.tcpdump.org/linktypes/LINKTYPE_NFLOG.html 2. The `nla_put(inst->skb, NFULA_TIMESTAMP, sizeof(ts), &ts))` call in net/netfilter/nfnetlink_log.c in the Linux kernel source. Add support for 16-byte and 12-byte seconds/microseconds time stamp, to match what we already have for seconds/nanoseconds time stamps, in `proto_tree_add_item()` etc., and use that. Fixes #19525.
2023-12-07epan: Remember whether heuristic dissectors are enabled by defaultJohn Thacker1-0/+9
Store whether or not heuristic dissectors are enabled by default. When reenabling protocols to their initial state, such as when changing profiles, also set heuristic dissectors back to their initial state. Also use the initial state in dissector_dump_heur_decodes so that it correctly displays the default state of a heuristic dissector, even if the heuristic dissector has been changed from the default. Fix #19520
2023-12-06Draft: Make LTE Uu stats and graph work for NR tooMartin Mathieson1-1/+1
2023-11-20Remove init of proto variablesStig Bjørlykke1-1/+1
Remove init of proto, header field, expert info and subtree variables. This will reduces the binary size by approximate 1266320 bytes due to using .bss to zero-initialize the fields. The conversion is done using the tools/convert-proto-init.py script.
2023-11-18epan: Fix truncation of BASE_OUI labelsJohn Thacker1-30/+35
There's been an assumption that INT32 based fields won't need labels longer than 32 bytes, and INT64 based fields no longer than 48. Buffers are declared to hold the integer labels. These buffers are all intermediate buffers allocated on the stack and used in static functions; none of them are the final returned label, which is ITEM_LABEL_LENGTH. BASE_OUI can require 64 bytes at most for the manufacturer string (including null), plus 11 extra bytes for the "XX:XX:XX ()" part. (Service names for port numbers ought to be limited to 15 characters, https://www.rfc-editor.org/rfc/rfc6335#section-5.1 ) Define NUMBER_LABEL_LENGTH and make it 80 bytes. That's smaller than ITEM_LABEL_LENGTH (240); it could be increased to ITEM_LABEL_LENGTH without trouble if necessary; using a #define make it easier to do so. Fix #18069.
2023-11-07epan: Initialize static proto values to 0Stig Bjørlykke1-9/+9
Update epan to not initialize static proto values to -1.
2023-11-02Initialize static proto values to 0Stig Bjørlykke1-10/+13
Add a script to initialize static proto values to 0 instead of -1. This will save ~1MB static init code.
2023-11-01tshark: fix memory leak when printing an IPv4 addressPascal Quantin1-5/+6
2023-10-30epan: Use available space for FT_BYTES labelsJohn Thacker1-10/+18
For custom columns, use the available column width. For display items, use the item width. Note that the bytes_to_str_maxlen functions take as parameter the number of bytes to display, so divide the string length by 2 or 3, depending on if we're using a separator. Labels and columns already have truncation mechanisms, so we can use that after passing in the full available widths. Fix #14265
2023-10-29IPv4: Fix wrong endianness displaying source/dest addressesJoão Valverde1-6/+2
Fixes 0d46d9a60a89b8d2fd37c91515f3c8153b5e6b99.
2023-10-27ftypes: Add IPv4 setter/getterJoão Valverde1-7/+11
Do not allow "fvalue_set_uinteger" and "fvalue_get_uinteger" with FT_IPv4. Use "fvalue_set_ipv4" and "fvalue_get_ipv4" intead. Fix incorrect usage of fvalue_*_uinteger with FT_IPv4, hopefully I caught all of them.
2023-10-23dfilter: Add "bitand" as an alternative operator keywordJoão Valverde1-0/+1
It's more compact than "bitwise_and" and inspired by C.
2023-10-21epan: Fix NTP time encoding edge caseJohn Thacker1-22/+54
In the NTP time encodings described by RFC 5905, "a value of zero is a special case representing unknown or unsynchronized time." As put by RFC 4330, "There will exist a 232-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp." The check for the zero value needs to occur *before* converting the fractional part of nanoseconds. Otherwise, four of the additional 232 picosecond intervals as unknown are truncated to 0 nanoseconds and incorrectly treated as unknown time. While it's unlikely that many clocks have a precision of 232 picoseconds, it's possible that an implementation that knows about how time is handled would intentionally use 0x00000001 for the fractional part so as to avoid indicating an unknown time. For the ENC_TIME_MSEC_NTP time, handle the alternative where the upper bytes are used for storing NTP Era information instead of being unused. Also require it to use at least 6 octets, as specified in ETSI TS 129.274, as fewer than 6 octets for an absolute time in milliseconds can only express less than 35 years. Also add a few other comments, e.g. that ENC_TIME_SECS_NTP should be used instead for the time without fractional seconds. Fix #18174
2023-10-13ftype: Clean up IPv6 interfaceJoão Valverde1-5/+8
Rename a typedef and use an address and mask as the method interface.
2023-10-10epan: Allow BASE_NO_DISPLAY_VALUE for string-like field typesJohn Thacker1-1/+1
Mask off the field display when checking string-like fields, the same as done for FT_BYTES and others, so that BASE_NO_DISPLAY_VALUE is allowed for string-like fields. This is useful for protocols that have large text payloads with known encodings that are used as header fields above a subtree or as payload fields, where it might be useful to access the entire string value, e.g. from tshark output, in the same way as byte arrays. Use this in SIP, where the same effect is currently being achieved by calling proto_item_set_text after creation with the field name.
2023-09-27epan: Fix compile errorStig Bjørlykke1-1/+1
Add the missing parameter to get_manuf_name_if_known() to fix a compile error.
2023-09-27proto.c: `proto_tree_add_mac48_detail()` functionDavid Perry1-0/+99
Create a public function in `epan/proto.c` to dissect a single MAC-48 address. Encapsulates the name and OUI resolution, and the LG and IG bit parsing. Created after observing that `packet-ieee80211.c` does not resolve the OUI or IG/LG bits for WLAN fields (`wlan.ra`, `wlan.da`, `wlan.sa`, `wlan.bssid`) the way that `packet-eth.c` does. This change modifies `packet-eth.c` and `packet-ieee80211.c` to use the new function. Add IG/LG bits
2023-09-22Make tfs_true_false the default for booleansJoão Valverde1-23/+4
Instead of adding a TFS(&tfs_true_false) to every boolean field, make it the default if "strings" is NULL. This seems to match the already existing documentation: If the Boolean field is to be displayed as "False" or "True", the 'strings' field would be set to NULL.
2023-09-15Prevent fvalue leaksJohn Thacker1-2/+20
Add a cleanup function in proto_tree_new_item for the newly created field_info's fvalue_t, so that if we throw an exception before adding the new node to the tree, the fvalue_t is properly freed. Pop it off without calling it if we do add the node. This is the function that adds nodes from values retrieved from the tvbuffer, so it can throw exceptions, particularly on variable length items like FT_STRINGZ, VARINTs, and FT_UINT_[STRING|BYTES].
2023-09-12epan: Free field info values that don't get added to the treeJohn Thacker1-0/+7
Normally field_info values added to the tree are freed in proto_tree_free_node. If proto_tree_add_node fails, and the passed in field_info is not added to a new node of the tree, free the field_info fvalue there so it doesn't leak.
2023-09-12epan: Fix leaks in proto_tree_add_bytes_itemJohn Thacker1-6/+16
Fix a couple leaks: Free the created GByteArray in the case where the encoding is not FT_STRING and the tree is non NULL. (We need to create it if the return value is non NULL, but don't really need to create it otherwise.) For FT_UINT_BYTES, don't create the GByteArray until we ensure that the entire length exists, not just the header length, so we don't leak it if we throw an exception verifying the entire length.
2023-09-07Clean up handling of string encodings for byte arrays and absolute times.Guy Harris1-40/+66
There is no reason to have separate "RFC 822" and "RFC 1123" parsing of Internet Message Format date/time values. RFC 1123 adds support for 4-digit years to RFC 822's 2-digit years; RFC 2822, which supplanted RFC 822, supports both, and RFC 5322, which supplanted RFC 2822, continues to do so. I know of no cases where *only* 2-digit years should be supported, especially given that it has beenover 23 years since January 1, 2000. Instead, have ENC_IMF_DATE_TIME for Internet Message Format date/time values; keep ENC_RFC_1123 for backwards compatibility, but treat it exactly the same as ENC_IMF_DATE_TIME. Keep ENC_RFC_822 around as an alias for ENC_IMF_DATE_TIME. Have separate expert infos for errors parsing string-encoded byte arrays and string-encoded dates and times, with the messages speaking of byte arrays and dates/times rather than "numbers". For now, have the only error being "couldn't convert"; we can add more for specific cases of what's wrong. In tvb_get_string_bytes() and tvb_get_string_time(), don't use errno as a way of indicating failure, use a return of NULL. Using errno 1) runs the risk of getting errno overwritten by intermediate calls and 2) would force assinging particular errno values, the set of which we don't control, to particular errors if we were to distinguish different errors in the future. In tvb_get_string_time(), for Internet Message Format date/time values, check for 2-digit and 3-digit years based on the length of the year field in the string. Handle them the way the RFCs say, not the way strptime() does (strptime(), which was originally written to allow programs to ask the user to specify a date and time and let them enter it in the locale's date and time format, and to use 2-digit years in case they were in the habit of doing so, which they might have been given that this was the mid 1980's; the choice of 1969 as the first "not 21st century" year was based on the fact that it was the earliest year for a date correspnding to a non-negative time_t value, which is UNIX-specific, unlike the Internet Message Format). Change tvb_get_string_time() to use guard clauses to handle errors; yes it involves gotos, but it's easier to read than nested ifs, for example. Update the Lua unit tests to reflect this.
2023-09-01dfilter: Add "nan" and "inf" as reserved keywordsJoão Valverde1-0/+2
Adds "nan" (not a number) and "inf" (infinity) as reserved keywords, to avoid clashes with protocols that want to use these filter names. Filter: _ws.ftypes.double == nan Instructions: 0000 READ_TREE _ws.ftypes.double <FT_DOUBLE> -> R0 0001 IF_FALSE_GOTO 3 0002 ANY_EQ R0 == nan <FT_DOUBLE> 0003 RETURN Filter: _ws.ftypes.double == -inf Instructions: 0000 READ_TREE _ws.ftypes.double <FT_DOUBLE> -> R0 0001 IF_FALSE_GOTO 3 0002 ANY_EQ R0 == -inf <FT_DOUBLE> 0003 RETURN
2023-09-01dfilter: Do not parse booleans as a value stringJoão Valverde1-0/+2
When parsing an expression such as Filter: _ws.ftypes.boolean == true Instructions: 0000 READ_TREE _ws.ftypes.boolean <FT_BOOLEAN> -> R0 0001 IF_FALSE_GOTO 3 0002 ANY_EQ R0 == 1 <FT_UINT64> 0003 RETURN it gives the wrong type. Conceptually there is no reason a boolean should be a value string. This commit also fixes the error message to avoid calling invalid boolean tokens "invalid numbers" when parsing booleans. The code now use g_ascii_strcasecmp() to accept true, True, trUE, etc. Initially the intention was to require non-numeric literals to start with an upper-case letter, to reserve lower-case for protocol names, but since "true" and "false" have been accepted as integers for a long time via value strings, that intention is dropped. As a consequence true/false are added to reserved keywords. After this change: Filter: _ws.ftypes.boolean == true Instructions: 0000 READ_TREE _ws.ftypes.boolean <FT_BOOLEAN> -> R0 0001 IF_FALSE_GOTO 3 0002 ANY_EQ R0 == 1 <FT_BOOLEAN> 0003 RETURN
2023-08-19tshark: Add more fields to -G protocols and -G heuristic-decodesNiels Widger1-2/+10
This commit adds new fields to the output of both `-G protocols` and `-G heuristic-decodes` in `tshark`. For `-G protocols`, three new fields (4, 5 and 6) have been appened to the existing ones: - Field 1: protocol name - Field 2: protocol short name - Field 3: protocol filter name - Field 4 (NEW): protocol enabled (e.g. "T" or "F") - Field 5 (NEW): protocol enabled by default (e.g. "T" or "F") - Field 6 (NEW): protocol can toggle (e.g. "T" or "F") For `-G heuristic-decodes`, similarly three new fields (4, 5 and 6) have been appended to the existing ones: - Field 1: underlying dissector (e.g. "tcp") - Field 2: name of heuristic decoder (e.g. "ucp") - Field 3: heuristic enabled (e.g. "T" or "F") - Field 4 (NEW): heuristic enabled by default (e.g. "T" or "F") - Field 5 (NEW): heuristic short name (e.g. "ucp_tcp") - Field 6 (NEW): heuristic display name (e.g. "UCP over TCP") The new fields added to `-G heuristic-decodes` are useful as the short name argument required for `--enable-heuristic` was not previously shown in the `-G heuristic-decodes` output.
2023-08-09epan: Fix up --disable-all-protocolsJohn Thacker1-19/+0
Commit af0691342b7e6bc2ef81a8430ae00680223337bc and commit 80ae370811595f294c65cb71e1d213d5b49e33fd both added proto_disable_all. Take the one from the 80ae370811595f294c65cb71e1d213d5b49e33fd, which made changes to allow protocols to be enabled by proto_enable_proto_by_name() even if they are not disabled by default, which allows --only-protocols to work without changing the disabled-by-default setting of a protocol. We don't want to change the disabled by default setting, because that causes the disabled status to be persistent even when changing Configuration Profiles with the GUI, instead of being reset. In general, command line options that temporarily override the Configuration Profile at startup are cleared when switching to a new profile via the profile, and we don't want to make an exception.
2023-08-08Add --only-protocols and --disable-all-protocols to tshark and rawshark.Juanma Sanchez1-0/+19
--disable-all-protocols will mark all protocols as disabled by default, and then disable them. Certain protocols can then be enabled one by one by using --enable-protocol. --only-protocols is a helper option to make it easier to enable only certain protocols It's equivalent to passing --disable-all-protocols and then several --enable-protocol options. It accepts a comma separated list of protocols. First all protocols will be disabled, and then all protocols included in the list will be enabled one by one. Side-note, it wouldn't make much sense to enable only "tcp" for example without enabling the protocols in the lower layers (e.g: eth, sll, ip, ipv6). In this case, something like --only-protocols eth,sll,ip,ipv6,tcp will generally be needed in order to make sure that TCP is decoded. Signed-off-by: Juanma Sanchez <juasanch@redhat.com>
2023-08-08signature of proto_tree_set_ipv6 was changed after this patch was writtenJonathan Landis1-1/+1
2023-08-08add new add-and-return functions to C APIJonathan Landis1-0/+156
2023-08-08bugfix: proto_tree_add_time_item *endoff should be offset not lengthJonathan Landis1-1/+1
2023-07-25epan: Register dynamic column fields and make them filterableJohn Thacker1-1/+2
Make the text of each registered column a FT_STRING field that can be filtered, prefixed with _ws.col - these work in display filters, filters in taps, coloring rules, Wireshark read filters, and in the -Y, -R, -e, and -j options to tshark. Use them as the default "Apply as Filter" value for the columns that aren't handled by anything else currently. Because only the columns formats that actually correspond to columns get filled in (invisible columns work), register and deregister the fields when the columns change. Use the lower case version of the rest of the COL_* define for each column as the field name. This adds a number of conditions to "when are the columns needed", including when the main display filter or any filter on a tap is using one of these fields. Custom columns are currently not implemented. For custom columns, the tree then has to be further primed with any fields used by the custom columns as well. (Perhaps that should happen in epan_dissect_run() - are there any cases where we construct the columns and don't want to prime with any field that custom columns contains? Possibly in taps that we know only use build in columns.) Thus, for performance reasons, you're better off matching an ordinary field if possible; it takes extra time to generate the columns and many of them are numeric types. (Note that you can always convert a non-string field to a string field if you want regex matching, consult the *wireshark-filter(4)* man page.) It does save a bit on typing (especially for a multifield custom column) and remembering the column title might be easier in some cases. The columns are set before the color filters, which means that you can have a color filter that depends on a built-in column like Info or Protocol. Remove the special handling for the -e option to tshark. Note that the behavior is a little different now, because fixed field names are used instead of the titles (using the titles allowed illegal filter names, because it wasn't going through the filter engine.) For default names, this means that they're no longer capitalized, so "_ws.col.info" instead of "_ws.col.Info" - hopefully a small price in exchange for the filters working everywhere. The output format for -T fields remains the same; all that special handling is removed (except for remembering if someone asked for a column field to know that columns should be constructed.) They're also set before the postdissectors, so postdissectors can have access. Anything that depends on whether a packet and previous packets are displayed (COL_DELTA_TIME_DIS or COL_CUMULATIVE_BYTES) doesn't work the way most people expect, so don't register fields for those. (The same is already true of color filters that use those, along with color filters that use the color filter fields.) Fix #16576. Fix #17971. Fix #4684. Fix #13491. Fix #13941.
2023-07-16epan: Fix crash on columns with many long string fieldsJohn Thacker1-0/+5
ws_label_strcpy, like strlcpy, returns the number of bytes it would have written in the case of overflow. proto_item_fill_display_label needs to return the actual number of bytes copied (which is what protoo_strlcpy does). Fix #19212
2023-07-16RTPS: Added CRC32 and MD5 checksum check and deleted unused hfsIsmael Mendez Matamoros1-0/+93
Added an option for checking the expected RTPS message checksum is the same as the received in the wire if checksum is CRC-32C or MD5. Also delted unused header filters. Introduced function proto_tree_add_checksum_bytes.
2023-07-08dfilter: Add XOR logical operatorJoão Valverde1-0/+1
Fixes #19186.
2023-07-07dfilter: Remove limitation using subtractionJoão Valverde1-0/+2
Remove the requirement for a space character to precede a minus token. Fixes #19189.
2023-07-03Add Unix time support for absolute time field typeJoão Valverde1-4/+1
Add ABSOLUTE_TIME_UNIX absolute time type, to allow date and time values to be represented in Unix time, besides other existing formats.
2023-06-26dflter: Fix semantics of fvalue lengthJoão Valverde1-17/+17
Do not mix wire size, a protocol property, with fvalue length, a property of certain types of objects (sequences). Rename ftype_length() to ftype_wire_size(). Do not return wire_size with fvalue_length() (use ftype_wire_size() instead). Make the semantic check reject taking the len() of objects that are not arrays or lists. If the (fixed) len() of a number is somehow useful we can add a different function for that.
2023-06-20ftypes: Rename IS_FT_* macrosJoão Valverde1-14/+14
Rename IS_FT_*() to FT_IS_*(). I find it to be more natural and a better namespace for a public interface.
2023-06-18Get rid of unnecessary casts.Guy Harris1-3/+3
snprintf(), sensibly, takes a size_t argument specifying the size of the buffer. g_snprintf(), bogusly, takes a gulong argument specifying the size of the buffer, so we had to do casts to avoid narrowing complaints, but we're just using snprintf() now (as we require C11 or later), and don't need the casts any more.