BTW, it seems I didn’t mention this in the original announcement: for the curious, the particular files shown in the Live Demo are from GNU Make 3.82.

Note:  The live demo works to varying degrees when run under various browsers.  At the moment, both Firefox (16.0.2) and IE9 (32-bit, 9.0.8112.16421) seem to have no issues, while Chrome (23.0.1271.64 m) works to some extent, but for some reason puts some of the CFGs extremely far down on the page.

The goal of this part of the 0.0.5 work is to address a number of the issues present with the current static HTML reports, and to simultaneously provide more dynamic, interactive, and ultimately more useful reports.

Existing Issues

The static reports generated by CoFlo through version 0.0.4 have a number of issues, two of which are:

1. The Control Flow Graph images, in many cases, are dimensionally extremely large, often not fitting on the screen.
   While work on the control flow graph generation engine will hopefully address this to some extent, it is unavoidable that many CFGs will, by their very nature, be too large to be meaningfully viewable as a static image on a webpage.
2. All of the images are on a single HTML page.
   The reports are basically a list of <img> tags containing the CFG images of each function in the single index.html file.  This often results in one extremely wide image causing the browser to put a horizontal scroll bar with a very wide “throw” at the bottom of the page, making it difficult to precisely navigate the intermediate-sized CFGs.  Also, having everything on one page makes for a poor user experience regardless.

Addressing the Issues

As I originally saw it, an interim solution which simply scaled any over-wide CFGs to fit the browser window would be more than adequate.  Sure, there’d still be too many of them on one page, but vertical scrolling only would be far less onerous than both vertical and horizontal scrolling, and I could always split things up later into, say, one index.html and the one page per analyzed file.  Furthermore, since this is the 21st century, how hard could this possibly be?  Set a “max-width: 100%” somewhere and we’re golden.

Right?

…right?

Well, as it turns out: wrong.  The first problem I ran into was that scaled PNGs look terrible.  So I switched to SVGs, a vector graphics format, which is both well suited for the task and – after a mere 10 years or so - finally supported in the latest releases of all major browsers.  Perfect!  So now all that’s left to do is set that “max-width: 100%” in a CSS style sheet somewhere, check the results in the major browsers (if only out of an excess of caution, I mean really, what could possibly go wrong), and we’re done…

Wrong again.  Worked as expected in some browsers, but on at least one other which shall remain nameless, it didn’t maintain the SVG’s aspect ratio.  Turns out, that even in the 21st century – i.e. The Future(tm) – there’s no standards-specified way to tell a web browser “If this SVG <object> is wider than the browser window, resize it and maintain its aspect ratio”.  So it was that I found myself entering the world of…

JavaScript

Google as I might, I could find absolutely no way to scale SVGs as I needed to without resorting to doing it manually with JavaScript.  So I read a few tutorials on line (I’ve been around a while and have written code in more languages than is probably healthy for one man, but I’d never crossed paths with JavaScript before) and put my new-found skills to work.  This post is getting long, so I won’t bore you with the details, but in my journey to the live demo, I ran into my fair share of stumbling blocks:

• The Same-Origin Policy
  Short form: If you point your browser at files on your local filesystem (i.e. not through a server), your browser will block certain actions which it ordinarily wouldn’t.  Need I mention that what is blocked varies wildly between browsers?
• The Dojo Toolkit
  Really neat and comprehensive JavaScript framework.  Was working great for what I was trying to do until I realized that it’s heart is made of pure AJAX – which runs afoul of – yep – the Same-Origin Policy.
• There’s not really a standard way to include SVG files into HTML files.
  There are at least three ways which work to varying degrees on different browsers, so I guess that’s something.
• You have to do a bit of DOM gymnastics to get an SVG’s ”naturalWidth” and “naturalHeight”.

So I settled on jQuery, jQuery UI, and a few other JavaScript libraries, and things are working reasonably well.

As always, thanks for your interest in CoFlo.

Gary R. Van Sickle

• if() statements now display the conditional expression in CFG output.
• Fixed segfault with constraints when no violations were found.
• Many misc improvements to reachability analysis and reporting.
• Added another multi-file constraints test case, this one slightly more real-world.
• Added connectedness test.
• Now adding impossible edges to unconnected blocks during CFG creation.
• Fixed tests/testsuite.at’s main.cpp check.
• Fixed broken dependencies which were resulting in the coflo executable not being rebuilt.
• Passing Autoconf/Automake-determined CPPFLAGS to DParser build now.

See the Downloads page for links to the source distribution, and the online User’s Manual for instructions on how to install CoFlo and get started using it.

As always, thank you for your interest in CoFlo,

Gary R. Van Sickle

• Marked improvements in ease of installation, particularly in relation to the Boost and DParser libraries.
• An expanded set of supported platforms.  CoFlo 0.0.3 has been tested on the following platforms:
• Cygwin
• Both x86 and x86_64 variants of the following Linux distributions:
• Fedora 15
• Fedora 16
• Mandriva 2011
• openSUSE 11.3
• openSUSE 11.4
• openSUSE 12.1
• Ubuntu 11.10

Head on over to the Downloads page for the source code.

Thank you for your interest in CoFlo,

Gary R. Van Sickle

• Boost 1.46.1 is required for building, not 1.42.0.
• A .png was missing from the tarballs.

ToolCompiler.cpp: In member function ‘int ToolCompiler::GenerateCFG(const 
std::string&, const std::string&)’:
ToolCompiler.cpp:86:58: error: 
‘struct boost::filesystem::path’ has no member named ‘generic_string’

I’ve been able to reproduce this, but as of this writing don’t have a fix.  I have verified that CoFlo 0.0.1 successfully builds on the following platform/Boost combinations:

• Ubuntu 32-bit / Boost 1.46.1
• Ubuntu 64-bit / Boost 1.46.1
• Fedora 15 32-bit / Boost 1.46.0
• Cygwin / Boost 1.47.0

If you run into this, I apologize for the inconvenience.  Expect a fix in the next day or so.

Gary R. Van Sickle

CoFlo is a Free and Open Source source code analysis tool which generates and analyzes control flow graphs from C and C++ source.  CoFlo is distributed under the terms of the GNU General Public License Version 3.

CoFlo’s ultimate target audience is all developers in need of a deeper inspection, analysis, understanding, and visualization of their C and C++ source code.  As of this first alpha release however, CoFlo’s target audience is early adopters who fit that description: Version 0.0.1 of CoFlo, while usable and arguably even useful, is very much in the early stages of development.  Expect CoFlo’s abilities to improve dramatically over the next several releases.

Check out the Gallery, the post below, and the User’s Manual for a small taste of what CoFlo can already do.  If that piques your interest, head on over to the Downloads area, grab the source code, and start putting CoFlo to use!

Thank you for visiting the CoFlo web site,

Gary R. Van Sickle