Slashdot Mirror

← Back to Domains

Domain: gimpel.com

Stories and comments across the archive that link to gimpel.com.

Comments · 16

  1. Does Lint Exist anymore by chopper749 · · Score: 1 · on Ask Slashdot: What Tools To Clean Up a Large C/C++ Project?

    http://www.gimpel.com/html/ind...

  2. Visual Studio by alexo · · Score: 1 · on What Free IDE Do You Use?

    I churn C++ code under VS2005 at work.
    All in all, I like the IDE, although free-floating edit windows would be nice.

    That said, I find Visual Assist indispensable.
    It is expensive but if you can get your employer to pay for it, I highly recommend it.

    I also use Artistic style (free) to reformat code, and PC-Lint ($$$) to find lurking problems.

  3. not surprised by stoolpigeon · · Score: 4, Insightful · on Dr. Dobb's Journal Going Web-Only

    When I got my January copy it was in a plastic bag with a brochure for sd west. The brochure was thicker than the magazine. I almost tossed the magazine and kept the brochure. So much has been cut back over the years. I will miss the bug of the month. It was an ad but it was fun. Maybe they'll still have it on the web version.

  4. Signal-to-noise ratio by mlimber · · Score: 1 · on Do Static Source Code Analysis Tools Really Work?
    You will need to do some tuning with a tool like Gimpel's PC-Lint, so it's best to use it from the get-go rather than try to start linting part way through or at the end of your project. Then you do some initial setup and make minor tweaks as you go, so the tuning process is not at all painful. Many tools, like PC-Lint, also integrate into IDEs like Visual Studio, and some have free add-on programs like ALOA (http://pera-software.com/htm/english/aloa.htm) which analyzes the output of PC-Lint to generate some metrics for the quality of the code.

    I have found such tools to be invaluable. I had code like this:
    class Lock {/*...*/};
    void Foo( Mutex& m )
    {
    Lock(m);
    // ...
    }

    This is valid syntax, but I intended to use that lock instance for the duration of the function, so the first line should have read "Lock lock(m);". Multithreading is tricky enough, and I looked at the real code for a long while, reading right over this bug. PC-Lint found it for me right away (thankfully, it was already tuned, and I should have been using it before running my code).

    But even though PC-Lint is pretty good, it ain't perfect. I have found that it has some trouble with advanced C++ templates (e.g., policy-based design). I have submitted bug reports for many of these problems, and they do seem responsive in working them in to the patches.

    Finally, here's an article from 2006 discussing the available static analysis available tools for C, C++, and Java and describing how and why to integrate it into your development process.

  5. Another fan (+ fan of PC Lint) by mike_diack · · Score: 1 · on Do Static Source Code Analysis Tools Really Work?

    I've been using static analysis tools since 1993 now and I'm totally convinced of their merits. I've found no compiler that yet comes close to being as capable at finding problems as the best static analysis tools are now.

    I develop medical software for cancer treatment professionally (which is keenly watched by the FDA) and thus am exceptionally keen to maintain bugfree code. While static analysis can't guarantee it, it can make a huge difference to code quality and reliability - and yes, to answer the original questioner, yes, they can catch stuff like buffer overruns, pointer abuse, memory leaks etc, and in some cases, resource/locking abuses etc. I will admit that gcc is very good these days, but even it isn't as good as these tools.

    In particular I'm a very big fan of Gimpel's PC Lint - which is astonishingly good and astonishly inexpensive.

    If you wish to try a demo of it, interactively, try their demo tool at:

    http://www.gimpel-online.com/OnlineTesting.html

    Also, they do a monthly "bug of the month" in a code sample - see whether your compiler can spot the issue/potential issue:

    http://www.gimpel.com/html/bugs.htm

    For anyone integrating it into Visual C++ (PC Lint is a command line tool), take a look at Riverblade's Visual Lint also:

    http://www.riverblade.co.uk/

    Disclaimer: I don't work for any of these companies (Gimpel or Riverblade) but I'm a huge fan of both of their products - I believe they've made more difference to my development than any number of UML tools etc - I tend to dump tools that don't make a real difference to me, and these are the only tools that I've used year in year out...

    (Gets off soapbox)

    Seriously though - whatever you choose, do investigate static analysis - it really is worth it.

  6. Re:Static analysis tools by sadr · · Score: 2 · on Do Static Source Code Analysis Tools Really Work?

    Here's another vote for PC-Lint by http://www.gimpel.com/

    You really can't beat it for the money, and it is probably as comprehensive as some of the other more expensive products for C and C++.

  7. FlexeLint / PC-lint by DoofusOfDeath · · Score: 4, Informative · on Static Code Analysis Tools?

    http://www.gimpel.com/html/lintinfo.htm/

    I've never tried it for a code base as large as 500k. My guess it that I used it up to 15k. I was very pleased with it. I agreed with just about every warning it raised, and was able to easily suppress individual instances or whole classes of errors. I also found it somewhat easier to get started with compared to the big tools from Rational et al.

    I think it's a bit pricey for a an open-source coder like me, but it should be cheap enough for a company with a tools budget.

  8. Run your code past PC-LINT by Weaselmancer · · Score: 1 · on Ultra-Stable Software Design in C++?

    No kidding. It will catch things most humans will miss. Check it out here. If you want to get an idea of the kinds of things it'll catch, check out their "bug of the month" page - it's a facinating read. You'd be surprised how many nearly-impossible to detect errors you can make in C++.

    Disclaimer: I don't work for Gimpel, YMMV, etc.

  9. Obfuscation is an industry nowdays! by dotnetwolf2003 · · Score: 1 · on Winners of the 18th IOCCC
    BTW, there are companies that produce obfuscation tools for automatic obfuscation of the code, and produce only those tools.

    For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

    So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

    Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

  10. Gimpel/PC-lint bug of the month by TimButterfield · · Score: 2 · on Brain Teasers for Coders?

    If this is to be strictly C/C++ oriented, a fairly steady supply of puzzles may be had by using Gimpel's Bug of the month. I have seen these for many years and have usually found them to be interesting and sometimes even educational.

  11. Whew... by neutralstone · · Score: 1 · on Introducing RMS-Lint

    In the split second before I realized it was AFD, I thought "Holy carp! He's going to compete with us!"

    Then I thought, "Waitaminute...remember Emacs?" Then I relaxed... :-)

    /me waits to be modded into oblivion.

  12. Re:Worst kind of science by mhifoe · · Score: 1 · on Software Code Quality Of Apache Analyzed
    I think you can paraphrase their description like this:

    We run PC-Lint or Splint on your source code.
    Then we tart up the output, stick it in a report and charge you 10 grand.

  13. What about PC-Lint? by unformed · · Score: 2 · on C with Safety - Cyclone

    (I'm not associated with this at all, but I read about it in Game Developer once, and it's really interesting.) @ Gimpel software.

    I generally don't like internal type-checking within a language, because it results in slowness, and some los of power. (Sometimes there are times you want to do things that you normally shouldn't be doing, in order to speed up routines.) A language which prevents "bad programming practice" ends up screwing itself over. However, having an external source-code checking utility that tests for bad programming, while still allowing complete power would be much more useful, to me, at least....

  14. More helpful tips for you by goingware · · Score: 2 · on Making Software Suck Less, Pt. II
    While I was out for a while I thought of a few more things to post that should have been included in the above.

    While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

    I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

    Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity
    Haim can write the most difficult code, and it doesn't just work right, it is unquestionable.

    Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

    If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

    For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

    Reading Risks for many years is what has made me such a zealot for software quality. It has also made me tend to avoid using software for anything of real importance in my life, and to feel uneasy while flying aboard modern aircraft - even though, with a B.A. in Physics, I am very comfortable with the aerodynamic principles that hold airplanes up and used to enjoy flying as a kid.

    If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

    But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

    The ACCU is interested in more than just C and C++ these days, if you program in those languages, Java or (dare I say it) C-sharp you should join. The mailing lists is pretty low traffic and has some of the best signal-to-noise ratio of any list I've seen (except Risks). The ACCU's technical journals, with articles written by the members, are a valuable source of information on such things as how to write exception-safe code.

    (Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

    And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

    If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

    After reading Effective C++ and More Effective C++, if you're programming with g++ (or using gcc to compile ".cpp" files) then you should use the -Weffc++ option to g++ to warn you about style problems. From the GCC Online Manual:

    -Weffc++ (C++ only)
    Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.
    Importantly, in any language, make sure your code compiles cleanly without warnings with all the warnings enabled in the compiler - use the -pedantic option in gcc.

    C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

    People who write in any programming language, from assembler on through C and way out to prolog, really should go back to our roots and read the early book:

    Sadly, this book is out of print, but see the "E" Titles Section at ACCU for other Elements of Style books.

    Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

    Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

    Looks like I missed one when I spoke about Bounded Pointers for GCC, Spotlight, etc. in my previous post. Parasoft offers:

    But note that these products use patented algorithms - number 5,581,696 and 5,860,011.

    You can search by patent number here.

    And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

    Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

    Finally, to make sure your HTML is valid, test it with the W3C HTML validation service. You have two choices of how to get your documents processed:

    Try this link for an example of running a popular web application through the W3C validator.


    Mike

  15. Fixing Someone Else's Broken Code; Resources by goingware · · Score: 4 · on Notes From the Cathedral
    I've been working as a programmer for 13 years now, and for most of my career, the way I described it is this:

    I've spent most of my career fixing somebody else's broken code.

    This is not to say that my own has always been of the very highest quality, but in fact I decided early on to try to come to a fundamental understanding of what was wrong with software development, to get very good at debugging (I say that debugging is a specialty on my homepage) and to learn to write better code.

    In my early years I was initially very shocked at what I'd discover in production use at companies. Over the years I just learned that that's standard practice, in commercial software, in-house software, and even in scientific software (where I have become convinced, because of my experiences with high-energy physics data analysis, that many scientific papers are published with erroneous measurements because of software bugs).

    Early on I read that something like 90% of software development is spent doing maintenance programming. Some of this is doing legitimate upgrading, but a lot of it is just spent fixing bugs, and even a lot of time spent doing upgrades would be more productive if the code were of better quality.

    After reading this figure and having so many experiences with software bugs, both other people's and my own, I decided very early on to get very good at debugging.

    One of the first things I did was adopt the regular use of "lint" for checking my C code. I would integrate lint targets into my makefiles and after editing a source file I would type "make lint" before compiling to objects and lint would check all the files that were out of date with the object modules. Pretty quickly I got to where I could write code that was nearly always lint-clean - but the existing code I worked on would make lint scream with hundreds if not thousands of complaints, often serious things like variables being used before they are initialized.

    One of the first solid clues I got about software quality came from Robert Ward's book "Debugging C" - now out of print, it predated the common use of source code debuggers and talked about how to write your own stack crawls and other tools.

    Ward emphasized the use of the Scientific Method in debugging, and because I was trained in physics, this came very naturally to me; before that I'd mostly floundered and used printf a lot.

    I've gotten very good at debugging and have even worked full-time as a debugger at Apple Computer where I was a "Debug Meister" and my business card gave my title as "Cybernetic Entomologist".

    I can easily get highly paid consulting work doing debugging for companies desperate to ship a product (and have in the past) but I don't really like to do it for various reasons, some of the same reasons I quit my debugging job at Apple.

    One is that if I only do debugging I don't have something to point to at the end of the day and say "I wrote that". I could say "that works because of me", but sadly there's usually lots of bugs left that I didn't have the time to find so I don't really feel proud of the result. The other problem is that the bugs are usually not there because of something interesting, it's not like the code is mostly good but there's some subtle flaws, rather the code is a heap of dung and I can go in with a pitchfork and do debugging wholesale until I get tired of it and the client or manager decides the rate new bugs are being found is low enough they can feel OK about shipping it.

    I don't feel good about contributing to such shoddiness. If a company is not good enough to support quality in their corporate culture I don't want to come in and put on a band-aid for them. It would be an entirely different thing if a company hired me to restructure their development process so that quality was a goal that was achieved through direct application of process but gee whiz no one has ever asked me to do that for them.

    I do have to say though that the best thing that ever happened to me is that I became a "technology prostitute" as the author of the original article puts it. One benefit of this is that the process is entirely of my own creation, and almost all of the work I've been given has been to write entirely new products from scratch, so I can engineer in quality from the beginning.

    Here's a few recommendations I have. Get good tools. Besides a compiler, editor and debugger, you need a static code checker and you also need dynamic testers. The ones I know about are (I haven't used them all yet):

    • PC-Lint static code checking for C and C++. It runs on Windows but Flexe-Lint comes as shrouded source code and is highly portable.
    • Spotlight dynamic tester for Mac PowerPC - I use this every day and recommend it highly
    • BoundsChecker dynamic tester for Windows
    • Purify dynamic tester for Unix (but apparently not Linux) and Windows NT
    • Optimizeit dynamic tester for Java - do you know many Java programs have memory leaks? Can you understand why? Not just Java but any garbage collected program.
    There's also memprof and electric fence, which I think run on Linux. It would be possible to modify gcc so that you program when built with debugging flags and linked with a special library would have all memory references boundschecked before allowing the access. This could work with both read and write access and would catch overruns by as little as one byte - Spotlight does this by patching the executable powerpc code and rewriting the debugging symbol table.

    Finally, to really come to understand the software quality problem in the industry and what you can do about it, read The Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks. The book The Software Conspiracy exposes the complete disregard the commercial software industry has for serving the consumer by providing quality products - I haven't read it yet but it looks interesting.

    A very interesting methodology that emphasizes personal responsibility and puts the fun back into programming as well as maintaining quality from the very start is Extreme Programming. I'm starting to adopt extreme programming (the the extent a one man operation can - I can't work in pairs :-/ ) and find it a tremendous benefit.

  16. Risks, the Software Conspiracy and Good Tools by goingware · · Score: 3 · on The Code War-- Software By Other Means
    Two valuable and pertinent links:

    The Forum on Risks to the Public in Computers and Related Systems

    The Software Conspiracy

    While there will always be quality problems in software, current practice in many companies is to not even try to do the basic things that tend towards improving software quality. Until the public wakes up and realizes they're being ripped off, and their safety and corporate information being put at risk, we will always have this problem.

    One solution is to get every programmer in a company a copy of some good quality tools, static analysis tools like PC-Lint and dynamic (runtime) analysis tools like Spotlight (for the MacOS) or BoundsChecker (for Windows) or Purify for Unix (but apparently not Linux) and NT.

    As a Spotlight user and a long-time reader of the Risks forum, I wouldn't dream of shipping a Mac product unless it tested absolutely cleanly under Spotlight and had zero memory leaks.

    But it is amazing to try Spotlight on a mature commercial product for the first time. Think you're program's free of bugs? Guess again. I proposed using Spotlight to my manager, on our program which had been shipping for several years and cost $600 retail. It was a serious product for high-end users. My manager said it would be a waste of time because "Our program has so many bugs, Spotlight would keep finding them and progress would be very slow." And you know, he was right. I persisted anyway, and spent three months ferreting bugs out of that program with Spotlight.

    There's a lot of tools out there (and there's tools like these for Java too, like OptimizeIt - do you know many Java programs have memory leaks?). You don't have to pick the tools I recommend, but look out for what's available there and make sure you have something for every developer seat in the house.

    It will be the best investment you make. The $199 for Spotlight will be paid for in the day it's first used.

    And free software writers, I suggest writing free software versions of these. It would be possible in principle to write a special version of gcc, or an command-like option to it, that when your program is linked to a special library all your memory accesses are boundschecked. Note that Spotlight can validate memory reads as well as memory writes.