Systemtap preprocessor and short-circuit boolean evaluation

[Andrew Stitcher <astitcher at redhat dot com>]

I have a systemtap script (which is investigating pthread mutex
behaviour) that wants to select whether to hook probes into
pthread_mutex_lock() or the futex syscall using a command line argument.

The effect I want to achieve is only if there is a command line argument
and only if it is set to "futex" should we do the futex probe otherwise
default into pthread_mutex_lock().

What Id like to be able to write is:

%( $# >= 1 && @1 == "futex" %?
probe syscall.futex.return
...
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)

However because && is not short circuiting in the preprocessor I have to
write (because if there is no first argument the boolean expression
raises an error on @1)

%( $# >= 1 %?
%( @1 == "futex"
%?
probe syscall.futex.return
...
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)
%:
probe
process("/lib64/libpthread.so.0").function("pthread_mutex_lock").return
...
%)

This repetition offends me! and could be a maintenance issue in the
script going forward. Have I missed some way to avoid the repetition?

Is the idea of short circuiting boolean operators bad in the context of
the systemtap preprocessor in some way which explains why it is not
implemented that way? Is there any chance it might get implemented?

Another way of fixing my problem would be to have @n return "" if the
argument is not present but I must say I don't especially like that
idea, although it is consistent with the behaviour of systemtap arrays.

[Using systemtap 1.6-1 on Fedora 16]

Thanks

Andrew