GNU variant of strerror_r() returns char *, while the XSI version returns int.
To make things worse, glibc ships both and added a unused result warning
in recent versions (2.16) causing the build to fail.
Add our own custom wrapper that always returns a pointer to the message buffer
and additionally make XSI versions of strerror_r() GNU compatible by
returning "Unknown error xxx" if no error message is available.
Fixes:
src/switch_rtp.c: In function 'rtp_common_read':
src/switch_rtp.c:3313:15: error: ignoring return value of 'strerror_r',
declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
*sigh* of course there are two versions of strerror_r():
char *strerror_r() - GNU
int strerror_r() - non-GNU
Revert and back the drawing board...
This reverts commit 3c82033e53.
The adj_port buffer was only 5 bytes wide, so we were truncating any
port numbers >= 10000 that were written to this variable as snprintf
ensures the last byte is null.
FS-4354 --resolve
When we're terminating ZRTP to an IVR or to a leg which is not
ZRTP-capable, there's no way for us to make an intelligent decision
about whether this flag should be set. For a client to consider the
SAS as verified, however, both sides need to set this flag. By always
setting this flag on our side, we leave the decision completely in the
hands of the client where we hope there is a careful human.
Signed-off-by: Travis Cross <tc@traviscross.com>
This amends commit 7bd9efc7f5.
We changed away from using unsigned here because it caused a warning
on Windows. Using the more specific type, however, is causing a
warning on gcc-4.7 (it notices that the switch statement contains
values not present in the specified enum type). So we're switching
back to unsigned here while keeping the type casts and hoping that
keeps Windows happy.
This amends commit 7bd9efc7f5.
Using the more explicit typedef causes gcc to warn about the
incompatible types for the reasons noted in the earlier commit
message. This is why we just used the unsigned type earlier so we
could avoid all this casting.
The things we do to make Windows happy...
According Jeff Lenk, Windows Visual Studio doesn't understand that
people use the char type for non-null-terminated byte arrays, so it
throws a warning about this that causes the build to fail on Windows.
As the initial value for the ZID doesn't really matter here one iota,
just null-terminate it on Windows.
libzrtp's sas_is_verified field is a uint32_t, but zrtp_verified_set
expects a uint8_t. This is a boolean field, so it doesn't matter one
way or the other. gcc doesn't care, but Windows Visual Studio
apparently throws a warning about this.
The callback here receives both zrtp_protocol_event_t and
zrtp_security_event_t events. The latter is numbered contiguously to
the former. Still, it's a bit confusing to have to pick one as a
type, but apparently this fixes a warning on Visual Studio on Windows.
Thanks to Jeff Lenk.
Anthony Minessale
Stefan Knoblich
Jeff Lenk
Travis Cross
Ken Rice