Hi,

I wonder if (and how) it is possible to prevent 
certain function/macros from being used.

For example we would like to produce a lint 
error/warning when the assert(...) macro is used 
since we, for various reasons, will use another 
assertion/contract mechanism.

I've tried playing with +emacro and +esym but I 
dont get anything to happen ;-)

Also, is there a way to produce user defined 
messages / codes since even if we do manage to 
trap the situation mentioned above I can't 
really fins a proper lint messgae code to /re)
use for it.

Thanks

You could define the assert-macro in Lint not to
be overwritten by any define in the code using the
'+d<name>=<value>' option (note the '+' sign!). If
you then use something illegal, you'll get a
message ;-)
You can use the option '+headerwarn(assert.h)' to
have Lint warn you about the use of the header
defining your unwanted macro.
And while you cannot define completely new
messages, you can append you own strings to
existing messages using '-append'.

HTH,

Johan Bezem
www.bezem.de

+headerwarn solved the problem.

Thanks!

There's another way also, in lint 8r and later.
You need to activate lint warning 586 in your lint
options, but you can then use the following lint
directives to handle "dangerous/deprecated" code:

The directive works for functions and macros and
variables (I think).

It takes the form:
-deprecate (object type, object name, user message)

e.g.

//lint -deprecate( function, unlink, This is now
deprecated in favour of _unlink in VC 2005 )

will cause a message of:
"This is now deprecated in favour of _unlink in VC
2005" whenever lint finds me using the unlink
function call.

Likewise:

An example of a macro check:

//lint -deprecate( macro, USES_CONVERSION, Be
careful string conversions are occuring here! )

will cause a message of:
"Be careful string conversions are occuring here!"
whenever lint finds me using the USES_CONVERSION
macro.

Question to Gimpel:
Why is there no mention of this new -deprecate in 
the read80.txt?
I also noticed it used in au-misra2.lnt

Does this avoid the assert/exit problems with 
misra as discussed in 
http://www.gimpel.com/Discussion.cfm?ThreadID=2184
?

Jan - drop me an email on this and I'll explain
why it's not documented.
Mike