Re: strcpy -> strlcpy?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Tue, Jan 04, 2005 at 04:17:39PM -0800, Matthew Dillon wrote:
> 
> It sounds like a better approach to detecting these sorts of
> bugs would be to have a separate code parser and analysis tool.  C
> is actually very easy to parse (having written a C compiler I can
> say that with assurance), and even not all that hard to analyze. 
> The hard part is producing the assembly/other output.  I'll bet it
> would be easier then trying to build it directly into the GCC
> framework.

Yeah, this is definitely how to do it.  CIL (url below) is a framework
for doing this already, and it can also do transformations on the output
code.  The clincher is the 'cilly' frontend which just pretends to be GCC
so you can compile using it directly.  If you can't just slot the static
analysis into your existing compile cycle by changing ${CC}, I think
you've lost a lot of people already (and it makes checking everything in
the ports tree incredibly easy).

Incidentally, real-world GNU/Microsoft C is pretty tough to parse ---
Necula has a great page on it:
http://manju.cs.berkeley.edu/cil/cil017.html
I spent some time trying to make the whole of OpenBSD be successfully
parsed by CIL, and found some pretty wierd corner cases, in addition to
all the various GNU C extensions that find their way into modern C code.

CIL: http://manju.cs.berkeley.edu/cil/

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk