We can't assume that time_t is 'long'. When building for win64 we get:
../f5.c: In function 'f5_configure':
../f5.c:690:63: warning: format '%ld' expects argument of type 'long int *', but argument 6 has type 'time_t *' {aka 'long long int *'} [-Wformat=]
690 | if (sscanf(cookie->value, "%dz%dz%dz%ldz%ld%c", &junk, &junk, &junk, &start, &dur, &c) >= 5
| ~~^ ~~~~~~
| | |
| long int * time_t * {aka long long int *}
| %lld
../f5.c:690:67: warning: format '%ld' expects argument of type 'long int *', but argument 7 has type 'time_t *' {aka 'long long int *'} [-Wformat=]
690 | if (sscanf(cookie->value, "%dz%dz%dz%ldz%ld%c", &junk, &junk, &junk, &start, &dur, &c) >= 5
| ~~^ ~~~~
| | |
| long int * time_t * {aka long long int *}
| %lld
Make it explicitly 'unsigned long long' instead.
Signed-off-by: David Woodhouse <email address hidden>
Merge branch 'optipng' of gitlab.com:openconnect/openconnect
eb479cf...
by
Dimitri Papadopoulos <email address hidden>
Ignore non-sensical NBNS/WINS server address
A VPN server sent the non-sensical NBNS/WINS server IP address 0.0.0.0.
I assume this is the default value in the VPN configuration. If so, it
could happen again. Do not pass this invalid default value to the script.
Depending on build options, libproxy-1.0.pc depends indirectly
on json-c.pc:
libproxy-1.0 -> gio-2.0 -> mount -> libcryptsetup -> json-c
This causes "pkg-config --cflags libproxy-1.0" to emit
"-I/usr/include/json-c".
json-c installs a "json.h" file that conflicts with the one provided by
json-parser. If json-c comes before json-parser on the compiler command,
we get a build failure:
openconnect-internal.h:1654:59: error: unknown type name 'json_value'
[ dwmw2: This is a combination of at *least* three different bugs in
three different packages conspiring to be my problem. See https://gitlab.com/openconnect/openconnect/-/merge_requests/476#note_1397129468
But still, working around it does no harm for now. Ironically, if the presence of json-c on the include path
wasn't *entirely* gratuitous then hiding it by putting it
last wouldn't actually work because then something would
fail to include the json-c version of <json.h> instead. ]
Bug: https://bugs.gentoo.org/906662
Signed-off-by: Mike Gilbert <email address hidden>
Signed-off-by: David Woodhouse <email address hidden>
We retrospectively added openconnect_set_sni() with the @OPENCONNECT_5_8
symbol version, *long* after API v5.8 was set in stone with the v9.00
release in April 2022.
Fix that by retconning it into a @OPENCONNECT_5_9 version which will be
part of the *next* release.
We have a unit test to prevent us from doing it again, and this commit
is the exception to the general rule that we should *never* commit to
libopenconnect5.symbols except as a side-effect of 'make tag' creating
a new release.
Fixes: 494edf49e628 ("Add openconnect_set_sni API function and Java setSNI() wrapper")
Signed-off-by: David Woodhouse <email address hidden>
