Those fetch gint and guint values, respectively, rather than values with
specified sizes in bits.
This should squelch Coverity CID 1457357.
Change-Id: Ia8f100bd3fe90c266e24a4346f80b2667c653b93
Reviewed-on: https://code.wireshark.org/review/36177
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Make ws_basetostru32(), and the other ws_baseto... routines, public, and
use ws_basetostru32() when parsing ranges, to detect additional errors
such as negative values.
Addresses part of
https://ask.wireshark.org/question/5538/preference-range/.
Change-Id: I00fac97a198a237b01b5cd9406ea32c220f80972
Reviewed-on: https://code.wireshark.org/review/30266
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Id73e641499e75bc1afc1dea29682418156f461fe
Reviewed-on: https://code.wireshark.org/review/24751
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Warning:
wireshark/wsutil/strtoi.c:113:1: warning: The left operand of '<' is a garbage value
DEFINE_WS_STRTOI_BITS(32)
^~~~~~~~~~~~~~~~~~~~~~~~~
wireshark/wsutil/strtoi.c:83:12: note: expanded from macro 'DEFINE_WS_STRTOI_BITS'
if (val < 0) \
~~~ ^
wireshark/wsutil/strtoi.c:114:1: warning: The left operand of '<' is a garbage value
DEFINE_WS_STRTOI_BITS(16)
^~~~~~~~~~~~~~~~~~~~~~~~~
wireshark/wsutil/strtoi.c:83:12: note: expanded from macro 'DEFINE_WS_STRTOI_BITS'
if (val < 0) \
~~~ ^
wireshark/wsutil/strtoi.c:115:1: warning: The left operand of '<' is a garbage value
DEFINE_WS_STRTOI_BITS(8)
^~~~~~~~~~~~~~~~~~~~~~~~
wireshark/wsutil/strtoi.c:83:12: note: expanded from macro 'DEFINE_WS_STRTOI_BITS'
if (val < 0) \
~~~ ^
3 warnings generated.
Change-Id: I9eef0f2c0d4500531655a8b43509205a1f4e0684
Reviewed-on: https://code.wireshark.org/review/18640
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Make the reply length unsigned - there's no reason for it to be signed.
Change-Id: I5f4d1f027eeddee939547c052220efb89800f4b1
Reviewed-on: https://code.wireshark.org/review/17740
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If the caller is not interested in checking its end, then it probably
wants a valid number only if the string contains a valid number. Add a
shortcut for this.
Change-Id: I39701bd445e29fb2606720b18ca3764c74a7255b
Reviewed-on: https://code.wireshark.org/review/17658
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Not all uses of atoi() or various strto* routines in Wireshark expect
the string to contain *only* a number, so not all uses should require
that the byte after the number be a '\0'. Have the ws_strto* routines
take a "pointer a pointer set to point to the character after the
number" argument, and have the callers do the appropriate checks of the
character after that.
This fixes the VMS trace reading code so that it can read those files
again.
The get_ routines are handed command-line arguments, so they *do* expect
the string to contain only a number; have them check to make sure the
byte after the number is a '\0'.
Change-Id: I46fc1bea7912b9278e385fe38491a0a2ad60d697
Reviewed-on: https://code.wireshark.org/review/17560
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, for signed values, the caller knows whether ERANGE means "too
large" or "too small"; this is analogous to what the C routines return.
Change-Id: Ifc1fc4723733be606487093f8aa77ae2d89d2c40
Reviewed-on: https://code.wireshark.org/review/17512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
-1 is not an unsigned number. For that matter, neither is +1;
"unsigned" means "without a sign", and they both have signs.
ANSI C's strto{whatever} routines - even the ones that supposedly are
for "unsigned" values - and the GLib routines modeled after them allow a
leading sign, so we have to check ourselves.
Change-Id: Ia0584bbf83394185cde88eec48efcdfa316f1c92
Reviewed-on: https://code.wireshark.org/review/17511
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In the current code many functions have been used for convertion
(strtol, atoi, g_ascii_strtoll, etc). Those utilities want to be
the only, shared, way to convert integers.
Change-Id: I22ba1bf54e144e73a4728612a4437de5a2d339e2
Reviewed-on: https://code.wireshark.org/review/17414
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Roland Knall <rknall@gmail.com>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Guy Harris