2.7 Known Problems

Nana has the following known features (or perhaps problems):

1. Nana macros which use the debugger such as DI or DL should be on lines by themselves. If you mix code and nana macros on the same line you will get errors, e.g:

             main(){
                int x;
                x = 5; x--; DI(x == 4);
             }
   

   This doesn't work since breakpoints are set at line boundaries rather than statement ones. Of course anyone who writes code like this deserves whatever happens to them.

2. Optimisation can remove variables so that debugger based assertions (‘DI.h’) do not work correctly. As usual the interaction between the debugger and the compiler is rather complicated. This may not be a problem if the appropriate compile-time flags are selected, e.g. ‘-O0 and -O1’ work on most platforms.
3. The ‘Q.h’ macros depend on the statement value extension to GNU CC so if you wish to use them you must use GCC. This can be fixed for C++ in a possibly useful manner, I can't see any solution for C.
4. The logging macros depend on the Var Args extension provided by the GNU C Preprocessor.¹ We could (probably will) implement a fix for this based on the tricks in the C FAQ. Unfortunately these tricks are not pretty. For now interested users could simply replace their CPP with the GNU CPP if they wished to stay with non-standard compilers.
5. The ‘Q.h’ macros do not work in the debugger since ‘gdb’ does support the statement expression extension.
6. Multiline expressions do not work as expected in the debugger since you need to use a blackslash as an escape at the end of the line. For example:

             	 DI(x +
                         10 > 30);
   

   A few backslashes may solve this particular problem.

7. Problems with the ‘configure’ script.

   The ‘configure’ script automatically detects the target operating system and architecture and then generates ‘nana-config.h’. If the options selected in ‘nana-config.h’ are incorrect they can be edited by hand and installed in the usual include directory. The easiest method is simply to delete all macros in ‘nana-config.h’ since the system defaults to more portable (and less efficient) implementations. If you wish to do this from the configure script you can try giving a unsupported machine type, e.g.

             % ./configure pdp11-dec-ultrix
   

8. Some users have reported problems with the configure script detecting vsnprintf. If configure doesn't find it and it does exist then simply define it in ‘nana-config.h’ as per the previous question.

   If vsnprintf really doesn't exist then get a new C library, possibly the GNU libc.

9. The use of vsprintf opens a security hole since no bounds checking is done by it. Nana attempts to use vsnprintf which is safe when it exists but it will resort to vsprintf if it can't find vsnprintf. All careful people should make sure that they have a library with vsnprintf.
10. Qstl.h doesn't work since the STL library has not been installed along with C++. This can of course be fixed by installing STL. See:
    ‘http://www.stl.org’
11. STL header file errors due to nana.

    The C++ STL header files for version 3.0 at least must be included before the Q.h file.

    The problem is caused by the STL files using S as a template argument. Of course Q.h uses S for summing a series. As usual namespace pollution strikes again.

    (Thanks to Han Holl for this particular problem).

12. If you try to use the debugger based macros such as DI.h or DL.h on code that has not been compiled with -g then misery follows.

    (Thanks to Eugen Dedu for this one)