asterisk

Commit Graph

Author	SHA1	Message	Date
Kevin Harwell	ec03909831	conversions: Add string to signed integer conversion functions Change-Id: Id603b0b03b78eb84c7fca030a08b343c0d5973f9	5 years ago
Kevin Harwell	def6bbc96b	conversions.c: Add conversions for largest max sized integer Added a conversion for umax (largest maximum sized integer allowed). Adjusted the other current conversion functions (uint and ulong) to be derivatives of the umax conversion since they are simply subsets of umax. Also made the negative check move the pointer on spaces since strtoumax does it anyways. Change-Id: I56c2ef2629d49b524c8df58af12951c181f81f08	6 years ago
Kevin Harwell	51375686f7	core/conversions: Added string to unsigned integer and long conversions Added functions that convert a string to an unsigned integer or unsigned long. A couple of unit test were also created to test the routines. The reasons for adding these conversion utilities (and hopefully eventually more) are as follows: * Conversion routines are functionally contained with consistent and better error checking * The function names offer a better description of what is happening * It encourages code reuse for easier bug fixing at a single source * It's simpler to use * It's unit testable For instance, currently in a lot of places when converting to an integer or similar the "sscanf" function is used. When using "sscanf" it may not be immediately clear what's happening as it lacks semantic naming. Limited error checking is usually done as well. For example, most of the time a check is done to make sure the value converted, but does not check for overflows or negative valued conversions when converting unsigned numbers. Why use/wrap "strtoul" and not "sscanf" then? Primarily, it lacks some of the built in error handling that "strtoul" has. For instance "strtoul" contains overflow checks. Less so, but can still factor as reasons, "sscanf" is slightly more complex in its use. And maybe a bit controversial, but it may be ("big if") potentially slower than "strtoul" in some cases. Change-Id: If7eaca4a48f8c7b89cc8b5a1f4bed2852fca82bb	8 years ago

Author

SHA1

Message

Date

Kevin Harwell

ec03909831

conversions: Add string to signed integer conversion functions

Change-Id: Id603b0b03b78eb84c7fca030a08b343c0d5973f9

Kevin Harwell

def6bbc96b

conversions.c: Add conversions for largest max sized integer

Added a conversion for umax (largest maximum sized integer allowed). Adjusted
the other current conversion functions (uint and ulong) to be derivatives of
the umax conversion since they are simply subsets of umax.

Also made the negative check move the pointer on spaces since strtoumax does it
anyways.

Change-Id: I56c2ef2629d49b524c8df58af12951c181f81f08

Kevin Harwell

51375686f7

core/conversions: Added string to unsigned integer and long conversions

Added functions that convert a string to an unsigned integer or unsigned long.
A couple of unit test were also created to test the routines. The reasons for
adding these conversion utilities (and hopefully eventually more) are as
follows:

  * Conversion routines are functionally contained with consistent and
    better error checking
  * The function names offer a better description of what is happening
  * It encourages code reuse for easier bug fixing at a single source
  * It's simpler to use
  * It's unit testable

For instance, currently in a lot of places when converting to an integer or
similar the "sscanf" function is used. When using "sscanf" it may not be
immediately clear what's happening as it lacks semantic naming. Limited error
checking is usually done as well. For example, most of the time a check is done
to make sure the value converted, but does not check for overflows or negative
valued conversions when converting unsigned numbers.

Why use/wrap "strtoul" and not "sscanf" then? Primarily, it lacks some of the
built in error handling that "strtoul" has. For instance "strtoul" contains
overflow checks. Less so, but can still factor as reasons, "sscanf" is slightly
more complex in its use. And maybe a bit controversial, but it may be ("big if")
potentially slower than "strtoul" in some cases.

Change-Id: If7eaca4a48f8c7b89cc8b5a1f4bed2852fca82bb

3 Commits (18.1)