Segmentation fault of rpm -E on builtin lua without a macro body

[devzero2000]

Running this command will cause a core dump

rpm -E '%{lua}'

This produce a malloc failed instead

rpm -E '%{perl}' ( I think the all the builtin - git , python - without the body do the same ).

This bug exists also on @rpm.org https://bugzilla.redhat.com/show_bug.cgi?id=972646 (i have just update it)

and was fixed trivially here http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=43a34e155432354454ba11b2d9decf86cfba26a6
but was reverted here http://rpm.org/gitweb?p=rpm.git;a=commit;h=f173f747cda11e3f6778d2553fcb0db4b4e1d571

[devzero2000 (pinto-elia)]

The final fix is in commit id ae5795897159319923b60f5c141a2ae5aa6f8d68

http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=ae5795897159319923b60f5c141a2ae5aa6f8d68

[Jeff Johnson (n3npq)]

There are 2 behaviors with embedded interpreters.

The first is %{lua:...} et al parsing which hasn't been (but SHOULD be) changed since forever:
the lua implementation has been left untouched (in so far as possible) in order to
guarantee "legacy compatibility". This behavior is
        $ ./rpm -E '%{lua}'
        Segmentation fault
The "fix" (whatever that means) is similar to whatever Panu did (but I slightly disagree with
Panu's comments regarding expanding empty bodies: package monkeys might benefit from
an error message rather than mysterious expansions of an empty script).

The other non-lua embeddings go through parseEmbedded() and display
        $ ./rpm -E '%{git}'
        memory alloc (4294967295 bytes) returned NULL.
which at least doesn't segfault even if the failure message is totally uninformative.

[Jeff Johnson (n3npq)]

Attached patch "fixes" both issues.

(aside)
There are other issues here, starting with what behavior one
"expects" from an interpreter.

For starters, there is no attempt to pass arguments to the embedded
lua interpreter for hysterical reasons. The "fix" would be to use
parseEmbedded() for lua as well as all the other embeddings.

The empty-body-in-embedded-interpreter analogue on the CLI is equivalent
to defining what one expects from, say,
        $ lua < /dev/null
One clearly expects an exit code from command execution, and on some
operating systems like *BSD, one sometimes expects a usage message. There
is also the EOF condition from feeding /dev/null (or "") to an interpreter

The problems with the analogy are:

1) Each interpreter can/will have different implementation defined behavior,
for /dev/null parsing preventing a common/simple rule for all RPM embedded interpreters.

2) The analogue of stdout that redirects output from embedded interpreters
into a macro expansion buffer isn't a general/complete as what is on the command line.

3) There is no analogue of a CLI command "exit code" available for a macro expansion

[devzero2000 (pinto-elia)]

Patch committed on branch 5.4

https://github.com/devzero2000/RPM5/commit/e0724b3b8016c5886156cf40a5278eaed63ff40