[Nobug] Outstanding NoBug todo's for near future

[Christian Thaeter]

While I am preparing a release within the next days now, there are still
some rough edges which should be improved soon after this release.

Some of this things need some help and testing I can not do alone.


Current Function, Compiler/Language detection:
(around line 104ff in nobug.h)

C99 defines __func__ to be a magic variable (const char __func__[] = ..)
When we use a C99 compiler this is mandated and pretty easy.

Not so with pre C99 and C++, neither defines a similar functionality but
most compilers have vendor extensions for that. There is a macro which
works for gcc/g++ which both define '__FUNCTION__' since 2.x (with
slightly different semantics, being magic string literals and not a
variable, but this is sufficient for NoBug).

Next the sun C compiler (cc) supports __FUNCTION__ since some time, we
check for the version 0x5100 since that what Jon confirms, probably
older sun C compilers supporting that too, please report if anyone has
such available. Note that the C99 detection above takes precendence as
the sun cc should already conform to C99, we actually didnt tried yet to
force it into some C89 mode and check if that works!

The sun C++ compiler (CC) is a different beast it neither defines
__FUNCTION__ nor __func__. But there is some compilerflag
'-features=extensions' which turns __func__ on. Now I can not rely or
mandate someone to compile his source with this flag and I need to
figure out somehow if it is enabled in the header (#if
extensions_is_on). I didn't investigated this someone else might help here.

So far no other compilers are cared for, but I now commit some generic
check which tests if either __FUNCTION__ or __func__ is a preprocessor
macro (which is in no way mandated by any standard). Finally there is
some safe fallback to "-".

A final word about gcc which supports __PRETTY_FUNCTION__ to show a
pretty printed prototype of C++ functions. I've decided not to use it
for serveral reasons. First, compiler support for such functionality is
very rare and then there is no standard way to pretty print prototypes.
When you use the nobug output to filter it with some scripts this may
yield some messy results when it doesnt met your expectations. Since the
function name is only a hint (there is filename and linenumber to locate
it) its not even necessary to pretty print the function. Moreover, the
header for each logged message uses ': ' as delimiter, while
functionnames are plain C/C++ identifiers and must not contain
whitespaces and colons, a pretty-printed protoype has not this restrictions.



GCC extensions:

I've pretty much made all gcc extensions I used optional to support
non-gcc compilers. There is only one case left in NOBUG_INJECT_GOODBAD
which uses 'expression-statements' that is: you can include statements
in expressions with the ({...}) syntax like:
 int a = 1 + ({printf("statement here\n"); 1});

I have no idea how to make this optional yet. For non GCC compilers I
will just disable the fault-injection features unless some way around
this is found.



Documentation/Manpage generation:

Generating the documentation has quite some hefty dependencies which I
think should not be mandated for packaging it (build dependencies). The
included README file is always a up to date text documentation, just
lacking some eye candy (and the graphviz generated diagram). But to make
NoBug more useful and fulfil debian packaging requirements it should
have an ordinary manpage. Long ago I added a half-hearted/unfinished
doc/nobug7.conf to extract a manpage from the existing documentation
(just facts/references, no blablah, possibly some short example at the
end). I will work a bit on generating the manpage next but I wont cry
for some help and suggestions about the manpage structure. The testsuite
(test.sh) has also some documentation now but it is very basic so far,
we have a ticket in the Lumiera trac asking for some helper to improve it.

Generating postscript and pdf looks quite awful yet, asciidoc defaults
seem to enable all bells and whistles but no style. Someone who has
experience with styling a docbook document (dblatex) is required to make
it look nice, I have absolutely no clue about this while I think it
would be nice when we can printout a few nobug manuals for FrOSCon as
giveaways to interested people.



	Christian