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.
Having identity strings in the settings key is problematic, as the parser can't
handle arbitrary characters in it. Further, the space separation makes it
impossible to define identities with spaces.
The new format uses key prefixes, similar to those used in local/remote auth
sections of connections. The secrets section takes subsections with type
prefixes, and each subsection uses "id" prefixes to define an arbitrary
number of identities.
Martin Willi