These definitions are directly derived from the RFC, so it should be safe
to cast them. clang complains about the different types, so cast them
explicitly.
The AES code historically has different build options for various size/speed
trade-offs. We never made use of them, so just drop the obsolete code. The code
now has four hard-coded fixed tables, both inverse and original.
Found due to %option nodefault. A match for } was actually missing
and # was not properly matched if it was part of an include statement
on the last line of a file that did not end with a newline.
With Bison 3.x support for YYLEX_PARAM has been removed and %lex-param
should be used. Unfortunately, that option does not take expressions.
Instead we use a wrapper function that calls the lexer with the proper
scanner object, which should also be backward compatible to older Bison
versions.
This is not thread safe. If threads are reading from pointers to existing
values they could get a partially updated invalid value.
Refactored assignment to a separate function.
This parser features several improvements over the existing one.
For instance, quoted strings (with escape sequences), unlimited includes,
relaxed newline handling (e.g. at the end of files or before/after { and }),
and the difference between empty and unset values (key = vs. key = "").
It also complains a lot more about invalid syntax. The current one accepts
pretty odd stuff (like settings or sections without name) without any
errors or warnings.
This enumerator is a wrapper around glob(3). If that function is not
supported NULL is returned. If no files match or an error occurs during
the pattern expansion an error is logged and the enumerator simply returns
no items.
RFC: if GLOB_ERR is not supplied glob returns GLOB_NOMATCH if e.g. the
base directory of the pattern does not exist, which would otherwise
result in an error. This way there is at least a clear error message in
case of a typo.
During shutdown, waiting for callbacks might never complete, as queued
callbacks might not get executed under certain conditions. Not the clean fix,
but works good enough for now.
Seen on Windows in vici tests.
While we don't add FDs with an active callback to the watched FDSET, we still
can get notifications for callbacks active due the asynchronous processing
of the same.
To avoid queue multiple callbacks, we check for queued callbacks before
activating new ones.
Using the same mechanism as the METHOD macro, the CALLBACK macro defines
a hybrid function signature. It strictly uses a weak void* for the first
function parameter, in contrast to the dynamic METHOD object "this" type.
This solves a problem with GNAT when compiling charon-tkm as __atomic*
built-ins are only provided in GCC 4.7 and newer.
Currently GNAT 4.6 and GCC 4.7.2 is shipped with Debian wheezy (stable),
as used in the testing environment. So while the configure script correctly
detected the __atomic* built-ins, and defined HAVE_GCC_ATOMIC_OPERATIONS,
this define turned out to be incorrect when charon-tkm was later built
with GNAT.
tests.load and tests.plugindir to allow the specification of the plugins
to be loaded and the directory to load them from.
Signed-off-by: Thomas Egerer <[email protected]>
By setting the environment variable TESTS_STRONGSWAN_CONF, the unit tests can
be asked to load a configuration file, thus enabling the tester to make use of
the usual configuration settings.
Signed-off-by: Thomas Egerer <[email protected]>
FreeBSD 10 deprecated the SIOCSIFADDR etc. commands, so we use this
newer command to set the address and netmask. A destination address
is now also required.
Fixes#566.
These are available since GCC 4.7 and will eventually replace the __sync
operations. They support the memory model defined by C++11. For instance,
by using __ATOMIC_RELAXED for some operations on the reference counters we
can avoid memory barriers, which are required by __sync operations (whose
memory model essentially is __ATOMIC_SEQ_CST).
On many architectures it is safe to read the value directly (those
using cache coherency protocols, and with atomic loads for 32-bit
values) but it is not if that's not the case or if we ever decide to
make refcount_t 64-bit (load not atomic on x86).
So make sure the operation is actually atomic and that users do not
have to care about the size of refcount_t.
Martin Willi