The dialog callback type actually returns INT_PTR even though it returns
a boolean value.
MSDN has the following to say:
> Type: INT_PTR
>
> Typically, the dialog box procedure should return TRUE if it
> processed the message, and FALSE if it did not. If the dialog box
> procedure returns FALSE, the dialog manager performs the default
> dialog operation in repsonse to the message.
Top work Microsoft!
GetDlgItem takes an integer as the identifier of the contol to be
retrieved. buflen is an unsigned integer. Assuming this code works
this just makes the truncation cast explicit. No functionality changes
but buflen *could* be over the limit of an integer. Very unlikey that
there will be a string that is 2^31 long though.
GetProcessId returns a DWORD (which is unsigned) and the HighPart or a
LARGE_INTEGER is a LONG (which is signed). As we are just doing some
hashing it is fine to cast this.
The declartion of the set_close_on_exec function has different
signatures on Windows and non-Windows platforms. This makes them
the same. Solves some casting issues.
On Windows the length to getnameinfo is a DWORD and socklen_t is an
integer. This results in sign conversion. On POSIX socklen_t is an
unsigned integer. Let's cast to unsigned to make both sides happy.
We shim the POSIX thread functionality for windows but don't use all
of the functions. This hides them behind ENABLE_USED_POSIX_FUNCTIONS
so that they can still exit if someone needs them in the future.
The code is attempting to reverse the byte order of a long which is
64bits on 64bit systems. This isn't possible so we should do the
conversion before the memory copy.
The h_addr_list is an array of pointers to network addresses for the host
in network byte order and it terminated by a null pointer. It is safe to
cast the address to a in_addr (which is effectively a uint32_t). However
we must cast it though void* to tell the compiler that we are OK with
the 1 byte alignment of the char pointer to a uint32_t pointer.
Shortening an integer to an unsigned char can lead to a situation where the
bottom 8 bits of the integer are all zeroes but the integer is actually
truthy. Using a ternary operator removes the ambiguity and solves compiler
warnings
Warning option -Wmissing-prototypes raises a warning for all functions
that are neither static nor in a header. Some functions should be available
only for main.c but not in the official header (civetweb.h) since they are
subject to changes. In order to avoid this warning, additional headers
outside the include folder must be added.
This warning option causes a flood of warnings in third party components,
so other warnings are no longer visible in the many pages of warnings.
For the moment remove this option again.
Later it could be activated for CivetWeb without the third_party folder.
There will never be a time when the length of a string can be negative.
This makes the function arguments semantically correct but also solves
some of the casting and bit shifting errors inside the function.
When shifting and ORing the bytes we should do it in the correct type
that we are going to assign to. In this case the types are signed and
unsigned so there is an implicit cast occuring.
The pattern length can never be negative, semantically it makes much more
sense to accept size_t as the pattern_length. This simplifies a lot of
the code elsewhere as the match_prefix is commonly called with
pattern_length set to the strlen which returns size_t
The mg_vsnprintf takes a size_t count but len is an integer. The value of
len should be greater than 0 from the previous statements so should be
safe to cast to size_t.
The result of sizeof is size_t so we should use the correct type.
We can safely cast the arithmetic to size_t as the while loop checks
that the subtraction will not result in a negative number.
