Oldies but goodies: the max depth is already initialized in declaration
to _MAX_MACRO_DEPTH which has been the same 16 since late nineties. This
wasn't always the case of course...
Send all through rpmlog(), unify formatting - previously echo and
warn were missing the trailing newline. The other change is that
echo now goes to stdout.
This simply breaks too many things - whole macro ecosystems exist based
on the assumption that quotes in arguments will pass to macros
untouched. Macro argument quoting support is necessary but it'll
need some entirely different approach that is either opt-in or
based on a different syntax altogether.
This reverts commit 47f0a899ef.
Some of scoping level values are defined in rpmmacros.h:
#define RMIL_DEFAULT -15
#define RMIL_MACROFILES -13
...
#define RMIL_GLOBAL 0
Before this patch RPM set these values decreased of 1 (for all macros).
Because of the (level - 1) in
pushMacro(dst, me->name, me->opts, me->body, (level - 1), me->flags);
in function copyMacros scoping level for some CMDLINE macros was decreased of 1.
Because of the (level - 1) in
pushMacro(mb->mc, n, o, b, (level - 1), ME_NONE);
in function doDefine scoping level values of all other macro types and
some CMDLINE macros was decreased of 1.
The patch shifts scoping level values back to the numbers defined
in rpmmacros.h.
This was spotted when investigating a regression introduced in
commit 237f35f16f where locally scoped
scoped macros did not get deleted on scope closing.
This also fixes the regression in question.
The first test in this patch tests automatic deleting of %defined macros.
The second test checks whether the behavior changed by
237f35f16f is still working correctly.
Thanks to Panu Matilainen for investigation and proposal of the main part
of the patch!
Single or double quotes can be used in macro arguments
as expected - they denote the begin and the end of the argument.
Example with 2-nd and 3-rd argument in double quotes:
./rpm --define "%foo() 1:%1 2:%2 3:%3" \
--eval '%foo Next_argument_will_be_empty "" "Last argument"'
1:Next_argument_will_be_empty 2: 3:Last argument
Example with all arguments in single quotes,
without spaces between arguments:
./rpm --define "%foo() 1:%1 2:%2 3:%3" \
--eval "%foo 'Next argument will be empty''''Last argument'"
1:Next argument will be empty 2: 3:Last argument
This essentially reverts commit 9ae7d1df31.
Leaving the testcase in place, just adjusting it to the expected
behavior where arguments that expand to empty are eaten away.
This actually matches what the shell does, so it follows the path of
least surprise in that sense - we emulate shell behavior with the
arguments etc already in many ways. What the shell has and rpm
has not is a way to pass those empty arguments by quoting. So
now we need a way to quote arguments - not just for passing empty
arguments but arguments containing whitespaces too.
There needs to be a way to pass escaped macros names (and other strings
containging %%) as parametric macro arguments. Add an internal mode
to preserve %% when expanding the arguments. Fixes a regression introduced
in commit 5adc56897b.
Thanks to Michael Schroeder for pointing this out!
This makes makes the behavior much more sensible eg in case an
argument expands to an empty strings, such as:
$ rpm --define '%foo() 1:%1 2:%2' --eval '%foo %nil bar'
After commit 5adc56897b rpm was
evaluating that to "1:bar 2:%2" which is hardly what you'd expect.
Thanks to Michael Schroeder for pointing this out! (#217)
This too is quite a fundamental change for macros: up to now, arguments
to parametric macros have not been expanded. It doesn't sound so bad
until you consider something like the case in RhBug:1397209:
%global rev 133
...
%setup %{?rev:-c}
%autosetup %{?rev:-c}
One would expect %setup and %autosetup behave the same when you replace
one with the other, but no. %setup gets "called" with -c, %autosetup
does not. Instead %autosetup receives a completely useless, literal
"%{?rev:-c}" as its argument. That's just brain-meltingly non-sensical.
This certainly has the potential to break advanced macro constructs,
but OTOH what breaks might well be only written that way in order to
work around the former behavior.
There are some funny subtleties involved as the argument expansion
must occur in the callers scope, ie before we create any of the
automatic macros. For example, Fedora's font packages break if only
this or the macro scope visibility enforcement is applied but start
working again once both are present.
When a parametric macro "calls" another parametric macro with fewer
arguments than it received, the inner macro would see the %<n>
macros of the outer call which is an obvious scoping violation
and quirky behavior, making macro writing harder than it needs be.
Similar scoping issues exist for manually defined macros but those
have further complications (because of %undefine semantics) that we
sheepishly avoid here by limiting the visibility enforcing to automatic
macros only (for now at least).
This changes the macro scoping rules quite fundamentally: macro
definitions are local to the parametric macro they were defined in,
and everything else is global. Among other things, this makes this
common spec idiom (RhBug:552944, RhBug:551971 etc) behave
deterministically because "foo" is placed into global scope:
%{?!foo: %define foo bar}
In theory it's certainly possible that this breaks somebodys carefully
crafted advanced macros but it seems quite unlikely, considering how
broken the alleged block-scoping has been. OTOH for macros defined
within parametric macros, nothing actually changes as that scoping has
always been enforced by rpm. The non-global define tracking is also
no longer needed for emitting warnings, because the case where it
was needed simply no longer exists.
Note that macro recursion depth is a different thing and still needs
to be tracked separately.
Since we actually setup all the same automatic macros whether there
are arguments or not, doing it centrally only makes sense. Shuffle
things around a bit in preparation for the next steps.
The missing space style-error has been recently coming common enough
somebody might think that IS the expected style, its not. Some of these
are actually very old, but fix across the board for consistency..
Strictly white-space only change.
The whole point of %trace is that some macro is being evaluated in a
surprising way, and you want to know what it is. This is often the
result of an unfortunately complex macro with difficult to see
intermediate results.
Shortening the output because it doesn't fit past 61 or so characters
does not help, and we have big screens these days. Don't do it.
Signed-off-by: Peter Jones <pjones@redhat.com>
In %trace mode, evaluating a macro which is undefined causes an invalid
read of 1 byte when searching for the end of the string:
trillian:~$ valgrind rpmspec --eval '%trace' --eval '%{?myUndefinedMacro}'
==21534== Memcheck, a memory error detector
==21534== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==21534== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==21534== Command: rpmspec --trace --eval %{?myUndefinedMacro}
==21534==
1> %{?myUndefinedMacro}^==21534== Invalid read of size 1
==21534== at 0x55018D4: printMacro (macro.c:296)
==21534== by 0x5502DFC: expandMacro (macro.c:1077)
==21534== by 0x5503710: doExpandMacros (macro.c:1280)
==21534== by 0x5504AB6: rpmExpand (macro.c:1629)
==21534== by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534== by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534== by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534== by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534== by 0x508F912: rpmcliInit (poptALL.c:302)
==21534== by 0x1095B2: main (rpmspec.c:63)
==21534== Address 0x8a010f3 is 0 bytes after a block of size 19 alloc'd
==21534== at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
==21534== by 0x5507C17: rmalloc (rpmmalloc.c:44)
==21534== by 0x5502788: expandMacro (macro.c:927)
==21534== by 0x5503710: doExpandMacros (macro.c:1280)
==21534== by 0x5504AB6: rpmExpand (macro.c:1629)
==21534== by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534== by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534== by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534== by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534== by 0x508F912: rpmcliInit (poptALL.c:302)
==21534== by 0x1095B2: main (rpmspec.c:63)
==21534==
1> %{?_transaction_color}^
1> %{?_prefer_color}^
1> %{_netsharedpath}^
1> %{_install_langs}^
==21534==
==21534== HEAP SUMMARY:
==21534== in use at exit: 7,183 bytes in 71 blocks
==21534== total heap usage: 7,811 allocs, 7,740 frees, 3,500,361 bytes allocated
==21534==
==21534== LEAK SUMMARY:
==21534== definitely lost: 19 bytes in 1 blocks
==21534== indirectly lost: 0 bytes in 0 blocks
==21534== possibly lost: 0 bytes in 0 blocks
==21534== still reachable: 7,164 bytes in 70 blocks
==21534== suppressed: 0 bytes in 0 blocks
==21534== Rerun with --leak-check=full to see details of leaked memory
==21534==
==21534== For counts of detected and suppressed errors, rerun with: -v
==21534== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 0 from 0)
trillian:~$
This can easily be avoided by checking the first byte as well as the
second for our sentinal value (NUL).
Signed-off-by: Peter Jones <pjones@redhat.com>
When a %{lua:...} macro calls rpm.expand(), it re-enters the macro
environment at depth zero regardless of what the "calling" nesting
level was. This could lead to wrong macros getting mopped out on
complex, nested lua + native macro calls.
Store the depth in global macro context and pick up the initial value
from there to keep the nesting level increasing on when entering %{lua:...}
space.
These haven't been in any public release yet so there's time to
fiddle with stuff like this. Both always succeed currently so no
change in that respect but it's better to have room for expansion...
This WILL cause behavior changes in cases where there have been
illegal macro names etc which have previously been more or less
ignored with an logged error, but now they will actually abort.
With direct rc assignments there's a risk that a previously
flagged error is overwritten by a success, only flagging errors
specifically avoids that. It also makes things simpler in some ways.
This probably changes *some* behavior wrt errors, in that errors
might actually get counted as such.
These are not deprecated at all no matter what the header has been
saying for the past 15+ years, they're used by rpm itself all over
the place as rpmDefineMacro() serves a slightly different purpose
and there's no rpmUndefineMacro() anyway.
Lets make 'em into proper citizens and move them into rpm namespace,
and while at it, call the operations push and pop since that's much
closer to what actually happens.
Finally, add simple wrapper macros to keep external code compilable
while getting the non-namespaced stuff out of ABI.
This allegedly been deprecated for no less than sixteen years,
but until very recently it's been in use by rpm itself and only
now with rpmExpandMacros() its possible to eliminate this one.
All sane external callers have been using rpmExpand() anyway
since expandMacros() is "buffer limited".
Now rpmExpandMacros() returns integer as a return value. Negative return
value implies failure. Return values can be more utilized in the future.
E. g. return value could specify how many macros were expanded in given
string.
This removes a seemingly undocumented, and not even well defined, limit
on the size of a macro expansion when parsing a spec file.
[lkardos@redhat.com: created new funtion expandMacrosU() (Unlimited)
instead of modifying expandMacros() in order not to change API/ABI]
Signed-off-by: Lubos Kardos <lkardos@redhat.com>
The problem evinced itself when somebody tried to use the macro
expansion on the string "%!". The problem was revealed by compiling
with "--fsanitize=memory" (rhbz:#1260248).
- Track non-global macro definitions in a helper variable, this
eliminates the need for costly macro table walking at end of each
expansion cycle as we only bother doing it if non-global macros
were defined during a given expansion cycle.
- Commit 1bdcd05008 to fix RhBug:1045723
broke some funky java macros in Fedora which include line continuation
in the argument (comments 6-7 in the bug). That it ever worked seems
far more like luck than by design but since this seems to fix it...
- Test for terminating ')' existence before copying, otherwise we'll
end up walking over the edge of the world.
- Return address from doDefine() on error will likely differ after
this, whether that actually affects anything remains to be seen...
- Both doDefine() and doUndefine() assumed the macro string would
always fit into MACROBUFSIZ, which of course is true for any
normal use but we cant make such assumptions.
- In the case of %define/%global there are various other overrun-issues
that need further changes to fix.
- In the current macro implementation the check is simply far too
expensive to leave on always. Its useful though, so enable it
when tracing macro expansion, in which case you're probably
troubleshooting some macro-issues...
- Reword the message to something hopefully little more understandable,
change from error to a warning (only matters for output)
- Check unused macros at end of every scope, but unlike with parametrized
macros, dont actually delete
- Only whine once per unused macro due to the above to avoid spurious
output due to above
- This catches the common error in specs where %define is used in a scope
unintentionally, eg "%{!?foo: %define foo 1}" where the just defined
macro should actually fall out of scope upon the closing }, but
only gets erased if any parametrized macro is "called" and causes
insane behavior such as described in RhBug:552944. So at least we'll
warn on these situations.
- In practise doesn't change anything visible as the "macro not used"
message is disabled, but tracking a flag bit is saner than
strlen() + strchr() + bunch of other stuff which isn't even correct:
prior to this %## would've triggered "unused" errors which is plain
wrong, and complaining about unused %1 %2 ... isn't really right
either.
- Revert back to pre commit c22d5b1299
state wrt macro substitution. The commit does have fixes we want
but it also breaks valid cases which is not okay. We really need
a far more thorough macro test suite before these kind of changes,
and also need to do the changes in more controlled pieces.
- Commit c22d5b1299 changed the parsing
to require a valid name in %{name} macro, but this outlaws existing
uses such as %{foo_%{bar}_something}. Relaxing the %{name} form
to use as-is substitution as well allows these to work again.
- Makes the testcase from commit f082b5baa4
succeed. While the old behavior is non-sensical and most likely entirely
unintentional, we're changing a very long-standing behavior here (tested
back to rpm 4.4.x and almost certainly much much older than that) so
its entirely possible people are actually relying on the old
behavior. Lets see what breaks...
- Allow loading custom macro files from eg specs. This is quite different
from %include which inlines arbitrary content into a spec, but which
cannot be used for including macro files as their syntax is entirely
different. Both have their uses.
- rpm5.org also supports %load within macro files, we dont as I find the
imperative %load very alien in what's otherwise an entirely declarative
file "format"
- Using the already calculated macro arg + arglen for copying the
buffer instead of buggy local variant helps... This is as old as
the embedded lua interpreter in rpm, close to a decade.
- Besides fixing the segfault, this actually makes it behave like
other built-ins, evaluating to empty string when an empty arguments
or no arguments are passed.
- Previously various built-in macros without an actual argument,
eg %{basename:} would evaluate to "}" which makes no sense
whatsoever. With this, they evaluate to an empty string similarly
to when no argument is passed, eg %{basename}. Arguably these
should emit an error/warning instead but for now...
- This reverts commit 43a34e1554,
contrary to what the comment said the is NOT how other built-ins
behave, they evaluate to an empty string without an argument.
Better fix needed...
- %{lua:...} is used for invoking the embedded Lua interpreter, in
which case the script must be passed as the macro argument. If
no argument is passed, let it fall through to normal macro expansion.
This might not be the most sensible behavior possible but at least
its in line with what currently happens with other similar built-in
macros.
- Add the actual locking into macro context acquire + release. We're
using a mutex instead of rwlock because currently any macro can
involve defines and undefines and we dont know it beforehand. So
we just use a bigger hammer...
- The macro engine internals shouldn't need recursive mutexes but
unfortunately Lua macro bindings, which are limited to the
lock-on-entry interfaces can and do get called recursively
from macros so currently there's not much choice but to use
recursive mutex for the macro contexts. What makes it even uglier
is that there's no portable static initializer for recursive mutex
so we need to add yet another pthread-construct to safely dynamically
initialize the mutexes :(
- Of course this doesn't make bunch of threads simultaneously messing
with macros behave sane: if one thread tries to load new macros
and the other one frees them, they shouldn't crash but the
results are unlikely to be what the caller intended. The purpose
here is just to allow the occasional rpmExpand() and such to
complete without crashing and burning when multiple threads are
doing stuff like trying to read packages from disk.
- rpmLoadMacros() is a dumb name for what it does: it copies macros
from one context to another. The only actual use within rpm is
to copy back the cli macros to global context, but make the
internal helper more flexible by allowing copying to any context.
- rpmLoadMacros() is mostly just a dumb wrapper around copyMacros()
to grab locks and guard against copying global context to itself.
Adjust rpmInitMacros() to use copyMacros() as it already has a
lock on the global table, it just needs a lock on the cli contexts
as well.
- rpmInitMacros() already grabs the (theoretical) lock on entry
so we shouldn't try to grab it again, use the new lockless
loadMacroFile() version for the purpose.
- rpmLoadMacroFile() is now just a simple lock-wrapper around
loadMacroFile()
- rpmLoadMacroFile() already grabs the (theoretical) lock on entry
so we shouldn't try to grab it again, use the new lockless
defineMacro() version for the purpose.
- rpmDefineMacro() is now just a simple lock-wrapper around defineMacro()
- Add and use dummy macro context lock acquire + release functions,
ATM these only centralize the NULL -> rpmGlobalMacroContext translation.
- Eliminate the NULL context translation from internal interfaces,
ensure its always done at the outer levels already.
- At least rpmLoadMacros() and rpmLoadMacroFile() are fishy wrt
theoretical locking at this point and will require further internal
helpers...
- Rename addMacro() and delMacro() to pushMacro() and popMacro()
respectively, change all internal callers to use the push/pop
variants. Make addMacro() and delMacro() just dummy wrappers
for the internal variants.
- No functional changes, just paving way for adding thread-safety
mutex: we'll be locking at the external API boundary to keep
things simple, avoid nested locking etc.
- Avoid the expensive calloc() when creating a macro expansion buffer,
malloc() suffices just as well as long as we initialize the first
byte in the buffer. This is easily visible on wall-clock times.
- Avoid recalculating source string length: when caller doesn't
pass slen, we always calculate the string length for creating
a terminated copy, no need to redo it...
- Add a warning comment about the seemingly obvious optimization
breaking macro undefining itself, this is starting to look like
a recurring theme :)
- Macro name, opts and body must not be freed or otherwise written
to after initialization, make them const pointers to clarify
(and enforce) this. Arena is used to store whatever we need: it
always contains the macro body, sometimes also name and/or opts,
but these can be pointers to elsewhere too.
In the existing implementation, when a new macro is added, the whole
table has to be sorted again. Hence the cost of adding n macros is
worse than O(n^2), due to arithmetic progression.
This change drops all qsort(3) stuff altogether, by carefully preserving
table in sorted order. In findEntry routine, bsearch(3) is replaced
with customized binary search which tracks position for insertion.
In the addMacro routine, if a matching entry is not found, this
position is used for direct insertion, after the rest of the elements
are "shifted to the right" with memmove(3). Likewise, in delMacro
routine, the elements are shifted back to the left when the last macro
definition is popped. Technically, shifting half of the array with
memmove(3) is still O(n^2); however, modern CPUs process contiguous
memory in a very efficient manner, and glibc provides a fine-tuned
memmove(3) implementation.
Also, macro table entries are now allocated in a single chunk.
This change reduces rpm startup costs by factor of 6. Also, this change
improves specfile parser performance by a factor of 2 (e.g. the parse
time of texlive.spec is reduced from 67s to 35s).
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
This change introduces a separate routine to parse for valid macro
names. Valid macro names are either regular 3+ character identifiers,
or special names: "S", "P", "0", "#", "*", "**", macro options such as
"-o" and "-o*", and macro arguments such as "1". Other names are not
valid. This fixes a number of bugs seen earlier due to sloppy name
parsing: "%_libdir*" and "%01" were not expanded (these are now expanded
to e.g. "/usr/lib64*" and "<name>1", as expected). This also fixes
bugs in as-is substitution: "%!foo" was expanded to "%foo", and likewise
"%!!!" was expanded to "%" (and to "%<garbage>" at EOL).
Also, bad names in %name and %{name...} substitutions are now handled
differently. In %name form, the name is parsed tentatively; a silent
fall-back to as-is substitution is provisioned when no valid name can
be obtain. In %{name...} form, a failure to obtain a valid name is now
a syntax error. Furthermore, only 3 variants are syntactically valid:
%{name} proper, %{name:...}, and %{name ...}. This renders invalid
ambiguous macro substitutions such as the one found in FC18 lvm2.spec:
Requires: util-linux >= %{util-linux_version}
error: Invalid macro syntax: %{util-linux_version}
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
When the output from a command is empty, nothing stops doShellEscape from
chopping newlines past the beginning of the buffer. This problem was first
identified by Dmitry V. Levin in July 2009.
Also, there is an off-by-one error in replacing trailing '\n' with '\0'.
This problem, however, escaped the attention of Dmitry V. Levin in July 2009.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
This will now issue a warning when macro definition is possibly
incorrect or ambigous, such as the one found in FC18 lvm2.spec:
%define util-linux_version 2.22.1
warning: Macro %util needs whitespace before body
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
'?' is returned by getopt when option is unknown, making hard to
pinpoint the actual bogus option...
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Teach %prep and %uncompress how to handle 7zip tarballs, with
the mingw toolchain landing in fedora, this may be useful when
crossbuilding Windows sources compressed using 7zip (CxImage is
one such project).
- 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.
- put some consistency into include ordering
- everything (apart from bits missed ;) is now ordered like this
1. "system.h"
2. other system includes
3. rpm public headers
4. rpm private headers
5. "debug.h"
Panu Matilainen