cygwin-gcc-fopen bug? (Purify)

Jim Kleckner
Fri Dec 10 20:33:00 GMT 2004

Dave Korn wrote:

>>-----Original Message-----
>>From: cygwin-owner On Behalf Of Jim Kleckner
>>Sent: 10 December 2004 19:01
>>We used to use Purify to find these sorts of problems
>>often just by running the program once.  Unfortunately
>>for us using cygwin, Purify appears to have moved toward
>>a firm dependence on VC.  Also, it is quite expensive.
>   AAArrgh!  It's a Rational tool!  Oh no, run away!

I feel your angst!  Though Purify was orignally
created by Pure Software as an awesome and unique
tool (and they got a patent for the object code
insertion technique).  Pure was bought by Rational
which was bought by IBM...

>>Has anyone out there gotten either Purify
>>or BoundsChecker to work with Cygwin?
>>I'll wager that if you could, Purify would
>>pinpoint a lot of tricky issues extremely
>>quickly.  Maybe a tool to munge the symbol
>>table into VC-compatible form?
>   Maybe we should try and port the free open-source equivalent valgrind
> ( instead?  I haven't ever looked at this, but it ought
> to be possible.  I note that you can use (a special variant version of) valgrind
> to verify win32 apps running on WINE.  So I guess there's a long-way-round to do
> that already....

Interesting tool and it looks promising.

In the original implementation, Purify didn't
even need a symbol table to instrument code let
alone be compiled or linked with the program,
though meaningful messages depended on it.  The
tool understood the machine architecture and
modified the code in-place (thus object code
insertion).  You could do checking on static
or dynamic libraries from vendors with or
without their cooperation along with your own
code.  Very very nice and comprehensive.

Without careful feature comparison, I can't be
sure, but I'll bet there are significant checks
that Purify does (if OCI is enabled) that Valgrind
does not do.


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list