Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/848#pullrequestreview-290938701___
This adds all of the rpmbuild popt aliases that expand to defines to
rpmspec as well.
It also changes --trace to include --POPTdesc argument help.
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online at:
Panu, this is still open. Any insight on this issue?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I also noticed it, but didn't want to check if it's still true ;)
I removed that sentence.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The duplicate error is because rpmExprStr/rpmExprBool ignore the return value
of the
`rdToken()` call. That should also be fixed.
It's not really about TOK_TERNARY_ALT, you'll get the same error with `%{expr:4
* +}`
If the different error message bothers you, just delete the TOK_EOF case so
Thanks. I'll need to take a proper look at this all, but this caught my eye
from the docs as it's getting moved around in the patch:
> There is currently an 8K limit on the size that this macro can expand to.
That's a *little* outdated info, might want to drop it while at it :D
--
You are
That'd work, but then we have inconsistent error messages depending on which
branch the error is in:
```
$ ./rpm --eval "%{expr:0 < 1 ? 0 : 4+}"
error: unexpected end of expression: 0 < 1 ? 0 : 4+
$ ./rpm --eval "%{expr:0 < 1 ? 4+ : 0}"
error: syntax error in expression: 0 < 1 ? 4+ : 0
error:
I now also documented the difference to `%{expr:}`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846#issuecomment-533100283___
@mlschroe pushed 2 commits.
c2469258af1915aeef5b44a6c1444a7a938d99d0 Add support for primary expansion to
the expression parser
d77df7f2275027228f15b674bbab59d9496adb61 Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this
I fixed the comment plus added some basic documentation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 2 commits.
02819e9b723f29329acaed20051f5a0cee10121a Add support for primary expansion to
the expression parser
3288db0c688e89131833258d9cac028fabf1e89e Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this
I think we just need a
```
exprErr(state, _("syntax error in expression"), state->p);
```
in doPrimary()'s default case to fix missing error for `%{expr:0 < 1 ? 4+ : 0}`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pavlinamv commented on this pull request.
> @@ -1349,6 +1386,13 @@ expandMacro(MacroBuf mb, const char *src, size_t slen)
doShellEscape(mb, s, (se - 1 - s));
s = se;
continue;
+ case '[': /* %[...] expression expansion */
+ if
@pmatilai pushed 1 commit.
203a47d2d8b7b499fba80d0fa5710429d17afbbe Fix double-free on ternary operator
parsing error
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Oh, right, got mixed up trying various different things. With eg bare words
(which is where I spotted this) both the true and false clauses report the
error, but with unexpected end of expression the error message is missing (but
it returns with exit code 1). I'll fix the test + commit
The false branch does get parsed, this needs to be fixed as well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, I just ran out of time yesterday but wanted to show your guys the current
state.
I've added some test cases, next comes the documentation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
good catch, thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/847#issuecomment-533060875___
Rpm-maint mailing list
v1 gets double-freed when theres an error parsing the result side
of the ternary operator. Add testcases to go, one that catches the
actual error and another which serves to demonstrate that the false
branch doesnt get parsed at all, errors or no.
You can view, comment on, or merge this pull
Hmph, there's an elephant or two in the room. Of course there is...
There are two major cases unresolved by this: fingerprinting, and rpm -V
verification. Fixing verify is merely annoying, but fingerprinting is much
harder and more intrusive as there are several far-apart places where we stat()
Yup, some testcases (along with docs) that show the behavior differences to
%{expr:...} would be appreciated.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool. It would be great to add a testcase.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846#issuecomment-533026052___
22 matches
Mail list logo
