File: cwarn.el.html

{{{ Documentation

Description:

CWarn is a package that highlights suspicious C and C++ constructions.

For example, take a look at the following piece of C code:

    if (x = 0);
      foo();

The code contains two, possibly fatal, bugs. The first is that the assignment operator "=" is used as part of the test; the user probably meant to use the comparison operator "==".

The second problem is that an extra semicolon is placed after closing parenthesis of the test expression. This makes the body of the if statement to be an empty statement, not the call to the function "foo", as the user probably intended.

This package is capable of highlighting the following C and C++ constructions:

* Assignments inside expressions, including variations like "+=".
* Semicolon following immediately after if, for, and while
  (except, of course, after a do .. while statement).
* C++ functions with reference parameters.

Note that none of the constructions highlighted (especially not C++ reference parameters) are considered errors by the language definitions.

Usage:

CWarn is implemented as two minor modes: cwarn-mode(var)/cwarn-mode(fun) and global-cwarn-mode(var)/global-cwarn-mode(fun). The former can be applied to individual buffers and the latter to all buffers.

Activate this package by Customize, or by placing the following line into the appropriate init file:

   (global-cwarn-mode 1)

Also, font-lock-mode(var)/font-lock-mode(fun) or global-font-lock-mode(var)/global-font-lock-mode(fun) must be enabled.

Afterthought:

After using this package for several weeks it feels as though I find stupid typo-style bugs while editing rather than at compile- or run-time, if I ever find them.

On the other hand, I find myself using assignments inside expressions much more often than I used to do. The reason is that there is no risk of interpreting an assignment operator as a comparison ("hey, the assignment operator is red, duh!").

Reporting bugs:

    Out of the last ten bugs you found, how many did you report?

When reporting a bug, please:

* Send a mail the maintainer of the package, or to the author
  if no maintainer exists.
* Include the name of the package in the title of the mail, to
  simplify for the recipient.
* State exactly what you did, what happened, and what you expected
  to see when you found the bug.
* If the bug cause an error, set the variable debug-on-error to t,
  repeat the operations that triggered the error and include
  the backtrace in the letter.
* If possible, include an example that activates the bug.
* Should you speculate about the cause of the problem, please
  state explicitly that you are guessing.

}}}

Defined variables (9)

Defined functions (10)

Defined faces (0)