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

The final fix is in commit id ae5795897159319923b60f5c141a2ae5aa6f8d68

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

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.

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

Patch committed on branch 5.4

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