Known Bugs

C-Breeze has a number of known bugs. This section describes a few of these, which remain because their causes are hard to find, or the cause is known but the solution is sufficiently difficult to implement that it has not yet been worth the effort.

1. C-Breeze is a work in progress, and as such some of the members of the various classes may be defunct or uninitialized, but still included in the header files. Also, some members are not intended to be initialized unless the user (you) specifically requests it with a call to some method; for instance, a lot of type information is this way. Don't assume something does what its name implies it does; make sure to test it first.

2. C-Breeze is not GCC. Although not exactly a bug, this can be annoying when trying to use glibc standard header files. In order to get certain functionality that many programs needs, C-Breeze can define the macro __GNUC__, that tells the header files that they are being read by GCC. Sometimes the header files think that this means it's OK to use GCC extensions not handled by C-Breeze, such as inline assembly language. C-Breeze can handle certain GCC extensions (as long as they are in header files, so that they'll be unparsed back to #include directives), but some others are not handles so easily. The workaround is to use or not use the -gcc flag on the C-Breeze command line. The presence or absence of this flag toggles certain preprocessor directives that try to accommodate weird GCCisms. If C-Breeze fails to compile a program, try using the -gcc flag and see if that helps. In particular, when using the stat(2) system call, the struct stat structure contains a field that is a scalar (a long long) when __GNUC__ is defined, but an array (of two ints) when it isn't defined. When this field is treated as a scalar by user code, you get problems.

3. Error messages produced by the C-Breeze parser are not always useful in tracking down invalid C syntax.