We can just use g_ascii_tolower() and g_ascii_toupper();
Change-Id: I8a88a096d16ce8c60dd9151e5bdddf6747702145
Reviewed-on: https://code.wireshark.org/review/4754
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, we don't have to worry about casting the argument (which, in
one place, was done wrong - casting to int preserves the sign-extension
done with signed chars), and don't have to worry about a locale in which
particular 8-bit byte values are considered alphanumeric characters.
Change-Id: I129b4bfdad70ade4ab6e0a1d2c13d59ae9e6f524
Reviewed-on: https://code.wireshark.org/review/4751
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If get_mac_lte_rapid_description() returned FALSE, we always used "" as
the description string; just have it return the string, or return "" if
rapid ranges haven't been configured, and just use the string.
(If the code ever needs to determine in other places whether rapid ranges
have been configured, it can check s_rapid_ranges_configured, or
get_mac_lte_rapid_description() could return NULL in that case and the
code using the string can check for a null value.)
This should squelch some incorrect used-but-not-set warnings from at
least one compiler.
Change-Id: I3ed495a4beb4a553e453e7bca764d1d8a07c5e53
Reviewed-on: https://code.wireshark.org/review/4750
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat all values in the alphabet as unsigned.
Change-Id: I4476c75352f32673a9cd131ea233465f3376fa25
Reviewed-on: https://code.wireshark.org/review/4747
Reviewed-by: Guy Harris <guy@alum.mit.edu>
order them from MSB to LSB
Change-Id: Ie758285c2cf5d19e00d6d256c49acca15ce81168
Reviewed-on: https://code.wireshark.org/review/4746
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: I636cfdfcd61d6d5dc041f9dbc657244d94e88b7f
Reviewed-on: https://code.wireshark.org/review/4745
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
containing the IE not the rest of the tvb.
Change-Id: I3eead5047b4f8de47e280ac447c66b110592bccd
Reviewed-on: https://code.wireshark.org/review/4744
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Casting a signed char with a negative value to int will preserve the
value, so it'll still be a negative subscript. Cast to guchar instead,
to make sure 0x80 through 0xFF are treated as 128 to 255, not -128 to
-1.
Change-Id: I1f0b33ba3686e963d45317b45465ff335431d17f
Reviewed-on: https://code.wireshark.org/review/4742
Reviewed-by: Guy Harris <guy@alum.mit.edu>
An unsigned 8-bit integer is always <= 0xFF; that was the cause of the
warning.
To see whether a byte, when represented as hex, has letters for its
upper and lower nibbles, just check whether both nibbles are >= 0xA.
Cast the extracted nibbles to make sure there's no sign-extension.
Change-Id: If4c7717a5d2fe341c02e9309ee6b89973a6ac292
Reviewed-on: https://code.wireshark.org/review/4739
Reviewed-by: Guy Harris <guy@alum.mit.edu>
C does not guarantee that char is signed (that's why there's a keyword
"signed"). Use gint8, to indicate that it's not a character, it's an
8-bit signed integer.
Change-Id: Id632df23352840cbc86a4d88f4c7dade95ab7837
Reviewed-on: https://code.wireshark.org/review/4736
Reviewed-by: Guy Harris <guy@alum.mit.edu>
C neither guarantees that char is signed nor that it's unsigned. Make
the str_to_nibble tables arrays of gint8, to make sure they can hold
numbers between 0 and 15 as well as -1. Cast gchar to guchar, not int,
when using it as a subscript into that array, so that the subscripts are
in the range 0 to 255, not -128 to 127.
Change-Id: Ib85de5aa4e83ae9efd808c78ce3f86f45b4a3f2a
Reviewed-on: https://code.wireshark.org/review/4734
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I'm not 100% certain the comparisons were right even with signed char;
make the comparisons unsigned vs. unsigned, regardless of whether char
is signed or not. (No, C doesn't require it to be signed; that's why
there's a "signed" keyword.)
Change-Id: Icbbd1019a2f7d4ebb40d821255834f825cd7c5a7
Reviewed-on: https://code.wireshark.org/review/4731
Reviewed-by: Guy Harris <guy@alum.mit.edu>
As requested by Michael Mann, most of the occurences of proto_tree_add_text/proto_item_add_subtree are replaced with proto_tree_add_subtree(_format) or proto_tree_add_item/proto_item_append_text in the non-generated files.
Change-Id: I27cccde88780adef43c78efd26333f47af098ad6
Reviewed-on: https://code.wireshark.org/review/4726
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
As requested by Michael Mann, all occurences of proto_tree_add_text/proto_item_add_subtree are replaced with proto_tree_add_subtree(_format) in the generated files. Our generator templates have also been updated accordingly.
Change-Id: I49ddd664dffef4b3ceda77edd1b2d7e01da363f3
Reviewed-on: https://code.wireshark.org/review/4725
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
I don't trust Packet Builder's ability to convert time stamps between
Capsa format and pcap.
Change-Id: I0ac2e14216e37127d81d5bf1c6d48a2c20841a8e
Reviewed-on: https://code.wireshark.org/review/4721
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Clean up a comment and indentation while we're at it.
Change-Id: Ia2b0a3f642849dcd464e04cdca13ff05c2fbe2e6
Reviewed-on: https://code.wireshark.org/review/4717
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Clean up the code to read the block according to that description.
Change-Id: Icb332e293c4b41d91989aa17a7546f298068e908
Reviewed-on: https://code.wireshark.org/review/4716
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Nothing from the SHB gets stored in the interfaces array - it's filled
in from IDBs - so it doesn't need to exist when we read the first SHB,
and thus doesn't need to be freed if the attempt to read the SHB gets an
error or a "this isn't a pcap-ng file" indication.
Update a comment while we're at it.
Change-Id: Ie67edb52dcf13c974607e95e290661bf48be68ae
Reviewed-on: https://code.wireshark.org/review/4711
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The block read routines don't need to return a "bytes read" amount any
more.
Have pcapng_read_block() just return an indication:
PCAPNG_BLOCK_OK - the read succeeded;
PCAPNG_BLOCK_NOT_SHB - the read failed in a fashion that
indicates that we might just not be reading a pcap-ng file;
PCAPNG_BLOCK_ERROR - the read failed in some other fashion
(i.e., we already have concluded that the file is a pcap-ng
file, or we got an I/O error).
In the cases where it needs to know whether it's reading the first block
for an open, have it check the shb_read flag, rather than being passed a
separate Boolean argument.
This means that pcapng_read_section_header_block() should return such an
indication as well.
Make the other block-reading routines return a Boolean success/failure
indication.
Change-Id: Id371457018a008ece9058d6042da44d631e51889
Reviewed-on: https://code.wireshark.org/review/4710
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add tfs_allocated_by_receiver_sender to tfs.h because it seems "popular" enough.
Change-Id: I478461d9b951a2c3e3aec6aaf996d95ba2c0feee
Reviewed-on: https://code.wireshark.org/review/4708
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This field indeed indicates the length of the Compartment Bitmap but *in 32-bit words*, which means that the value of 12 means the compartment bitmap is 48 bytes long.
Issue found by boaz
Bug:10561
Change-Id: I6c6ac25d0680837594d7cc6d2e4807a60a523b80
Reviewed-on: https://code.wireshark.org/review/4697
Reviewed-by: Michael Mann <mmann78@netscape.net>
A few fields weren't being zeroed and were causing valgrind warnings.
Bug: 10569
Change-Id: I30e1e70c9445376806f385f3578b65bf6e320f8b
Reviewed-on: https://code.wireshark.org/review/4702
Reviewed-by: Evan Huus <eapache@gmail.com>
This was reported by Emre Baris.
Change-Id: Ia37527e2a612fcbabd3ce7c6d8faf33905bbe52d
Reviewed-on: https://code.wireshark.org/review/4701
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
This should fix crash in 'tshark -G values' seen on 64 bit tshark.
Change-Id: Ia183fc5d5604f71b824cf4f758c18ff1ccd4540f
Reviewed-on: https://code.wireshark.org/review/4694
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Don't check a possibly-byte-swapped length against the minimum SHB size;
it'll probably look huge if it's byte-swapped, so the test won't fail
even if it is too small, and a really huge SHB's length could look too
small if it's byte-swapped.
Do the check *after* we've read the fixed-length portion of the block;
yes, that means we've read past the purported size of the block at that
point, but if that read succeeds, that doesn't matter, and if that read
fails, it just means we'll report "file cut short" rather than "bad SHB
length", *both* of which are problems with the file.
Change-Id: Ie3b5700662f2a6da40d373a84f00a8fc2cf0ce1b
Reviewed-on: https://code.wireshark.org/review/4692
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Recent changes must have made it not do so in some cases, and
our current version of file_tell(), unlike ftell() around which the
older file_tell() was a wrapper, is known to be cheap (ftell() would
make a system call to get the position). Just use file_tell() before
each read.
(Further cleanup is called for.)
Bug: 10568
Change-Id: Ib92057b2b87ec6eb16fd612bc91baeb668d1e1c7
Reviewed-on: https://code.wireshark.org/review/4691
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Check whether the block-type hash table exists before trynig to look
up anything in it.
Change-Id: I0aeb7f6454903bfcbdd0716909a0b72851d87233
Reviewed-on: https://code.wireshark.org/review/4689
Reviewed-by: Guy Harris <guy@alum.mit.edu>
... to ensure that there are no potential issues with respect to
editors limiting the number of lines scanned at the end of the file
when checking for editor modelines.
Change-Id: Ic85cbb108bb5159d6ec4116fea11f5eebb4e44a4
Reviewed-on: https://code.wireshark.org/review/4688
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Bug: 10534
Change-Id: Id56008da0c21a5f3a0309cdf21aff287c7820dcf
Reviewed-on: https://code.wireshark.org/review/4372
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The time stamps aren't known to be right, so don't provide them - that
way, instead of users reading Capsa files and getting the wrong idea
about the time stamps, they'll get no time stamps and have to ask for
our help, at which point we can ask them for *their* help in seeing what
Capsa thinks the time stamps are. (The joys of reverse-engineering.)
Change-Id: I77e12c09f2bc74b50a1b2b226fa6da3e8c0fedf9
Reviewed-on: https://code.wireshark.org/review/4685
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(So why can't GCC or Clang be taught to warn about *all* implicit
shortenings, as MSVC does, not just 64-bit-to-32-bit shortenings?)
Change-Id: I88c0b0aa2f1b306f58952589ff8bcae17bc29768
Reviewed-on: https://code.wireshark.org/review/4676
Reviewed-by: Guy Harris <guy@alum.mit.edu>
