- This isn't strictly needed as we're terminating the buffers "just in
case" all over the place but handling this centrally might allow
some day eliminating the other fluff...
- Oops, remember to reserve space for the trailing \0 when appending.
mb->nb holds the number of actual characters left in the buffer,
not the terminator. Fixes a regression introduced in rpm 4.9.x
dynamic macro realloction work (RhBug:431009 reprise)
- Actually protect against NULL mep (shouldn't happen but...)
- Remove bogus comment + add actually relevant comments
- Make the *mep reassignment more obvious by taking it out of
the if where its easily missed
- Replace dead NULL-assignments with a trash-n-burn memset()
- Fixup indentation to match general rpm style
- Lift the printbuffer accounting out of rpmlua into a struct of
its own (Funny thing, this looks a whole lot like the macro
expansion buffer and Good Ole StringBuf Brothers ... Boys ... Mam.
Unify them one of these days maybe)
- Replace the simplistic on/off printbuffer with a stack of buffers,
fixup the lone caller to use the new internal push/pop API.
- fopen() returns NULL on errors, never an opened stream with error
flag set. These are leftovers from past where rpmio fd was used
instead of FILE and probably the checks were bogus even back then too.
- A macro can undefine itself, and unless we grab a copy of it we'll
end up accessing already freed memory. Fixes a regression from
commit ebc4ceaaeb which assumed
a copy is not always needed.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- expandMacro() is big and ugly already, but handling the non-terminated
substrings there once and for all avoids having to ping-pong recurse
through couple of helpers to get there.
- Return the dynamically allocated expansion buffer to callers from
expandU(), except using a slightly less cryptic expandThis() name
for it now. Also deal with non-terminated strings centrally in
expandThis() instead of doing alloc + copy to terminate in every caller.
- Eliminate the underlying limitation of macro expansion limit by
growing the buffer as needed when adding characters to it. This
doesn't fix the entire issue yet however: expandU() and expandMacros()
are still limited to caller-specified buffer size, and output
from lua-macros isn't dynamically resized. One step at a time...
- Turn expandMacros() into a wrapper around internal doExpandMacros()
which returns the expanded string in a newly allocated buffer, use
the internal version for rpmExpand() too.
- In the cases where expandT() was called with strlen(source) we can
now just bypass it and call expandMacro() directly, avoiding an
unnecessary string copy.
- the "fix" breaks seemingly legitimate use in fedora font package
macros, possibly some funky interaction with %{lua: } macros or something
- this reverts commit f895acd285.
- Prior to this, local defines in constructs like %{!?foo: %define foo bar}
would remain defined until a parametrized macro gets called, causing
obscure and confusing errors in specs such as RhBug:551971 and countless
others. Use of %global is now always required for such constructs.
- define %_rpmconfigdir via %getconfdir in the main macro config, this
avoids it getting lost on macro reloads as happens when building
several packages at once
- one-shot to determine configuration base directory path from
RPM_CONFIGDIR environement or build-time default
- rpmfileutil is a bit strange place, this would really belong to librpm
but Lua initialization needs the path so...
- precalculate unexpanded size and allocate enough for that plus MACROBUFSIZ
for expansion
- typical allocation is way smaller than what gets allocated "just in case",
calculate expanded size and realloc to actual size to avoid wasting
memory
- expandMacro() wants the next \0 character to be returned, which might
or might not be the same as lastc passed to grabArgs()
- use memcpy() instead of memmove() for the copy, the areas can't overlap
- Use argvSplit() for splitting the macro path to components instead of
manual pointer-parsery.
- If URL's are to be supported or accepted at all (previous code attempted
to skip them), ':' is a very poor delimiter character.
Panu Matilainen