generic classes for safe %macro substitution

Simon Hausmann hausmann at kde.org
Wed Jan 1 18:29:42 GMT 2003


On Wed, Jan 01, 2003 at 06:01:41PM +0100, Oswald Buddenhagen wrote:
> moin!
> 
> as macro expansions (aka "expandos") are needed all over the place, i've
> written some classes for this task. they handle four types of expandos
> (with/without prefix * explicity/implicitly delimited) and two types of
> substitution (plain-text (for display) and bourne-shell escaped (for
> ::system, kshellprocess, etc.)).
> the shell-quote part needs some attention. the code contains a parser
> that tracks quoting in all posix-constructs and some bash extensions.
> i think i got the shell syntax right so far. however, bash has a bug
> which makes using expandos within double-quoted substitutions inherently
> insecure, so never use constructs like 'theprog "${foo:-%bar}"'. i also
> considered refusing macro expansion in this case, but i think users
> which use such complex constructs can be expected to know how their
> shell works (and not everybody has a broken /bin/sh, so why should we
> prevent them from using it the way they want). we should only put a
> warning in the documentation.
> 
> the class names are somewhat scary. if you can think of equally
> descriptive shorter names, then yell.

One thought: I find it confusing to see KMacroExpanderBase
inheriting from KMacroExpander (just naming wise) . Why not just
merge the two classes?

> the derived classes got messier than expected, to be honest.
> do you think it would make sense to remove the non-static versions of
> the functions together with the set*() methods?

I for one would remove the static methods instead :)

> in case you're wondering about the "goto nohit" ... i looked at the asm
> gcc generates for the complex expression i originally used and it was
> not fun. so i helped it a bit ...
> 
> give it some hammering.
> simply save the attachements, adopt the paths in Makefile and run
> make && ./kmxtest.
> some docu needs to be added before i can add it to kdelibs/kdecore,
> obviuosly.

Which applications would make use of these classes (besides kdm) ?

Simon




More information about the kde-core-devel mailing list