Commit cb4e5e755a added flags arguments
to rpmExprBool() and rpmExprStr(), but unfortunately rpm 4.15 sailed
with flagless versions them. It's extremely unlikely that anything out
there is actually using these, but then you never really know.
Rpm soname bumps are so inconvenient that we really do not want to do
that just for these two, so preserve binary compatibility and restore
flagless variants of both, adjust internal code to use flagged versions
always. If only we had symbol versioning, sigh.
Whether a macro is defined can be tested with eg rpmExpandNumeric()
but this is somewhat cumbersome and expensive for such a simple thing.
Prior to this, there was no way to find out whether a macro is
parametric (aka parameterized) or not.
%{expand:...} is a rather special built-in as its *purpose* is to
double-expand its argument, so it makes sense to separate it from
the others.
No functional changes intended here.
%{uncompress:...} is fairly complicated as far as builtin macros go:
it needs to first expand its argument to discover the actual file
its supposed to look at, then determine whether the file exists and
what sort of compression to use, then determine the macro to use
for decompressing that kind of file, expand said macro and finally
catenate the expanded argument to the lot. That's a lot of goo to
do inline doFoo(), so refactor it into a separate function.
Up to now the last step was implemented by re-expanding the argument
too, which makes it impossible to reliably handle paths with percent
signs. Just expand the command, and catenate the argument as deity
intended.
Additionally make behavior with empty argument consistent with other
builtins: %{uncompress:} expands to nothing instead of printing out
an error message with an empty filename.
We can't assume that a buffer allocated for one thing is sufficient
for another thing. The S and P macros share the same exact logic,
refactor to use common code to avoid having to fix twice, cleaning
up doFoo() a bit in the process.
Fixes: #1019
Before this commit, there was an "escape" flag that made the macro
expansion keep '%%' escapes. But this did not work for macros
that returned an '%' character by other means.
Remove the old escape mechanism and instead double the '%' characters
when the body is split into argument.
Fixes: #1055
If we're using libgcrypt for hashing we need to initialise libgcrypt as
otherwise it is not thread-safe. Without this it will crash when used
in parallel packaging runs.
Fixes#968
POSIX.1-2008 marked ctime() as obsolete and recommends strftime() instead.
We get two flies on one stroke as ctime() is also classified "dangerous"
by LGTM due to not being thread-safe.
strftime(..., "%c"...) isn't exactly the same as ctime() but is consistent
with what we use elsewhere and sufficient for debug purposes anyway.
rpmlua.h was originally written in a way that allows it to be included
regardless of whether Lua is actually enabled in rpm or not, or where
Lua headers are, specifically to isolate the rest of rpm from these
details. That was changed in commit 62bd62286a
when <lauxlib.h> started getting included in rpmlua.h, which leaks to
places like librpmbuild which do not directly use Lua.
The way Lua typedef's the luaL_Reg struct to itself defies my C fu for
for handling this in some nicer typesafe way, fix this all by just using
a void pointer instead, this is just an internal API where buyer can be
expected to beware.
Fixes#888
This makes the operators return the last evaluated term instead
of a boolean value. For example 2 || 3 will return 2.
We also allow strings by using boolifyValue(), allowing
expressions like "%{?foo}" || "default".
The %if lines in the specfile are expanded before the expressions
get evaluated, so the re-expansion of strings is surprising.
It's also not done for integers, which makes it inconsistent.
The original expression parser seems to have been written
without taking the upfront expansion into account, thus the
string expansion and the TOK_IDENTIFIER code.
As I can't imagine anybody using this feature lets just drop it.
Identifier expansion got broken in 2000 when getMacroBody() was
removed from the API (commit 3ad99fcba5).
Nobody seemed to have noticied, so it's safe to say that there is
no one that used it the intented way.
With the bad commit there is an unintended use for it: it is
a way to specify a string without the otherwise needed quotes.
So this commit might break some existing spec files, but cleaning
those up is easy and makes the world a better place.
The calculation of the slen parameter was not correct, as it didn't
account for already processed characters. The parameter itself was
also not used to limit the passed string, as the code assumed zero
termination. Thus we can as well simplify the code by using strlen()
on the passed string.
If an expression multiline like:
%{expr: 0 || 0 ||
0 || 0 |o| 0 ||
0 || 0 || 0 }
then it is better not to support marker pointing to the exact
place of the error.
Supports the same expressions as spec %if conditions because, well,
it's the same expression parser. Only this returns the result as
a string instead of a boolean.
The error messages created by the parser have been truly lame and with
zero context. No to mention typos such as multiple instances of "suported".
Add an error reporting helper which uses the parse state to report not
only the expression where the error occurred but also pinpoints the exact
character in the cases where we easily can, eg:
error: syntax error in expression: (1 && 0)) + 5
error: ^
Panu Matilainen