hmmmm.....
ok on line 130 what supposed to happen is that the ole extraction code tests
the first char of the ole file, the logic is that it the char isnt the char
that ole is supposed to start with then you get "barf no ole". The actual code
tests to see if the char is a printable char before it does the test to see if
the char is actually the right one.. So maybe some insane implementation of
isprint is allowing 0xd0 as a printable char, so i've put the tests the other
way around. Try again with the new cvsed one. I'm a bit doubtful that this
simple fix will change anything, seeing as the standalone wv hasn't had a
problem with this issue previously, but could someone give the new cvs wv tree
a check.
>If anybody wants me to email them a few samples files I'm having problems with
>then I can do, I'll not post them to the list since it'll be about 200K and
>that's not too nice over slow dial-up links :-)
You can always mail one or two to me, but id bet that they'll work on my setup
already.
btw, putting in that macro to use __LINE__ and __FILE__ has really been an
incredibly helpful remote debugging facility, i'd reccomend it for anyone.
C.
>
>Yours,
>Ian.
>
>--
>#ifndef __COMMON_SENSE__ | Ian Phillips
>#include <std_disclaimer> | TIBCO Software Inc.
>#endif | www.TIBCO.com
Real Life: Caolan McNamara * Doing: MSc in HCI
Work: Caolan.McNamara@ul.ie * Phone: +353-86-8790257
URL: http://www.csn.ul.ie/~caolan * Sig: an oblique strategy
The most important thing is the thing most easily forgotten