This is could be a bug if the len is greater than INT64_MAX, but the
code doesn't seem to care about this, so adding the explicit cast
to remove the compiler warning.
These casts convert the result of signed arithmetic into the correct
size_t type that the function accept. This doesn't alter any of the
logic in the function just tells the compiler that we know what we are
doing with respect to the conversions. This patch highlights that more
thorough reviews of the overflow of the arithmetic are needed before
assuming conversion to unsigned is acceptable.
There is a implicit cast from an integer to size_t for the length
parameter to mg_read. This patch makes that cast implicit by casting
the len to size_t. This doesn't check if the len is negative but it
shouldn't need to because if mg_read is given a huge number to read
(because the calculation wrapped around) it will just read until the
end of the socket data.
The previous code would do a unbounded memmove if the discard_len was
greater than the data_len. This patch puts a check in place to make sure
we do not do huge memory moves due to an integer wrapping around into
the unsigned size_t type. This occurs due to an implicit cast from the
subtraction
When comparing the queue size it must be an integer otherwise there
is a implicit conversion to an integer. The local QUEUE_SIZE macro
allows for a simple and concise way to do this.
We should never have a negative amount of listening sockets so there
is no need to have the number as a signed integer. This solves a lot
of signed conversion issues and is more semantically correct.
When subtracting the string lengths the result is a ptrdiff_t which
is signed. When we assign that to the vec->len field we do an
implicit conversion to unsigned. This makes that conversion explicit.
When subtracting the string lengths the result is a ptrdiff_t which
is signed. When we assign that to the vec->len field we do an
implicit conversion to unsigned. This makes that conversion explicit.
When DEBUG_TRACE isn't used it removes the functions from the body
of the code. This can lead to subtle bugs though as the following
will result in unexpected behaviour:
if (whatever)
DEBUG_TRACE(trace some stuff here)
foobar()
When DEBUG_TRACE is enabled it will be called when `whatever` is true.
However, when DEBUG_TRACE is removed the `foobar()` function call is
then absorbed into the conditional.
Compliant c++ compilers define __cplusplus to a long integer depending on
the version of C++:
* C++ pre-C++98 - `1`
* C++98 - `19971L`
* C++11 - `201103L`
* C++14 - `201402L`
Any compiler that states that it is C++11 compilant should have
static_assert available
C compilers define __STDC_VERSION__ to:
* C89 - `1` (but not always defined)
* C94 - `199409L`
* C99 - `199901L`
* C11 - `201112L`
C11 has the _Static_assert keyword
When reporting an error if parse_http_message were to fail, sending back user input as is to the client poses a security risk to browsers. I propose removing the string in the error reporting.
