Might want to note that this is also the default format, so using it is
generally redundant.
--
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/837#issuecomment-53269_
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.
You ca
I think that adding ternary operator support to the expression parser is useful
and it will not cause problems in the parsing of the existing expressions.
There is one thing that can be improved -cases like:
```
--eval '%{expr: 1 ?}'
--eval '%{expr: 0 ? 3 : }'
```
returns an error, but witho
Yes, there is no need to use ":string". But it is supported.
--
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/837#issuecomment-532153072_
I modeled the code after the other operators. Things like `--eval '%{expr: 4
+}'` have the same problem.
--
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/838#issuecomment-53
Identifier expansion got broken in 2000 when getMacroBody() was
removed from the API (commit ad99fcba52fcc5e8ab636d2f1760c945cdfbf19).
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
Expressions like '5 +' did not print an error message before.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/841
-- Commit Summary --
* Print an error for expressions with missing operands
-- File Changes --
M rpmio/e
I've opened another pull request that fixes the error printing as this is
unrelated to the ternary operator.
--
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/838#issuecommen
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/841#pullrequestreview-289276563___
Rpm
Conan-Kudo approved this pull request.
I guess if no one noticed for ~19 years...
--
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/840#pullrequestreview-289277566_
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/837#pullrequestreview-289278320___
Rpm
@pmatilai Is this something you want to also include for rpm 4.15?
--
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/836#issuecomment-532231485
The problem is that many people do not know that `%var != string` is not valid
syntax. Even Panu used `a!=b` in the test suite. I prefer ripping out the code
because the currently only `[a-zA-Z][a-zA-Z0-9]*` is supported (it's supposed
to match an identifier, but note the missing `_`) and thus i
Ok, I'll create a pull request tomorrow. Is it ok to add a `flags` argument to
rpmExprBool()/rpmExprStr() or is the API fixed and we need new functions? I'm
asking because they are in rpm-4.15.x and you probably don't want to cherry
pick this into 4.15?
The flags would be `RPMEXPR_EXPAND_STRING
@mlschroe Wait, even *I* use `%if %var != "string"`... That won't work anymore?
--
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/840#issuecomment-532286213___
I was about to write that this still works, but it really depends on to what
`%var` expands. It'll most likely be an error and you need to write `%if "%var"
!= "string"`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
Heaves forbid, no. Not at this point in the release process.
--
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/836#issuecomment-532534818__
Yes, and I'm asking that you mention it is the default format to make people
aware that it's something they don't need to use. It's basically a side-effect
of a code cleanup (in commit 2bfc0fad3876bcee0143664cae9f0f0107a86a33), not
something that ever needed using or advertising.
--
You are re
Ack. Thanks for the patch.
--
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/841#issuecomment-532543277___
Rpm-maint mailing list
R
Merged #841 into master.
--
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/841#event-2642318082___
Rpm-maint mailing list
Rpm-maint
I'm thinking that with these new developments, we'd better revert %{expr:..}
entirely from 4.15, we don't want people adopting it if the behavior is just
about to change. Pulling it into 4.15 felt a bit hasty anyway, apparently for a
good reason.
Along with that change I think we can sneak in a
21 matches
Mail list logo
