-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello, David,
Thanks for your great work. Just for your information, I created now a
branch in CVS called "fs_experimental", where I add to the libwpd-stream
library a second implementation WPXStreamImplementation.{cpp,h} and
WPXOLEStream.{cpp,h}. I would be glad if you could base your tests on
that one, since it is passing correctly my unit tests (make check) and
also the regression suite in CVS regression module.
It is possible that the msvc iostream implementation has some
differences and it would be really nice to make the stuff as portable as
possible. If we manage to make this work on msvc too, I am quite eager
to merge this branch to the HEAD and make it part of 0.8.10.
BTW: concerning the msvc "secure" versions of functions. I know that the
"insecure" ones are emitting warnings, but the "secure" ones are not
there before the msvc 2005 and are not portable at all. If one wants to
use them, to ifdef them with the correct _MSC_VER would be very
necessary. But, IMHO, one can just disregard the warnings and use the
old ones for the while at least.
Cheers
Fridrich
David Hislop wrote:
> At 12:58 am 06/04/2007, David Hislop wrote:
>> At 07:39 pm 05/04/2007, Ariya Hidayat wrote:
>>>> It's recognising the OLE container and the WP magic and header, but
>>>> getting
>>>> confused somewhere in the parser. It's also not recognising a "normal"
>>>> WordPerfect file. If I get a chance over the weekend I'll sort those
>>>> out.
>>>
>>> Could you elaborate on this?
>>> I'd be happy to help once more information is available.
>>
>> OK: first, I'm a C++ newbie, so please excuse the ignorance. Dealing
>> with the second issue, not recognising a "normal" WordPerfect file:
>
> I've partially solved this issue. Turns out that when readsome() is
> called, the input buffer really is empty. Changing readsome() to read()
> allows the file to be read and the WPC magic recognised. It's reading
> some garbage at the start of the file, so probably not positioning
> correctly, but at least that's the same problem as the document in an
> OLE container.
>
> I've no real idea why readsome() isn't finding data in the buffer here
> yet it works in wps2text. Possibly something I've done that isn't
> exactly right. WPDocument::isFileFormatSupported copies the
> WPSInputStream input to WPXInputStream document if it's not an OLE
> stream, and does
> header = WPXHeader::constructHeader(document)
> Perhaps that's it.
>
> Anyway, now I'll try sorting out the positioning issue.
>
> regards - David
>
>
>> 1. WPSFileStream::isOLEStream() works fine called from
>> WPDocument::isFileFormatSupported . d->buffer << d->file.rdbuf() reads
>> a chunk of the file into d->buffer, and the WP magic is obvious in
>> bytes 2-4 of _Stringbuffer .
>>
>> 2. Problems occur later in WPDocument::isFileFormatSupported calling
>> WPXHeader::constructHeader. The call to readU8 in the line
>> fileMagic[i] = readU8(input) throws an exception because numBytesRead
>> is zero. Tracing the input->read call to WPSFileStream::read and then
>> into the istream code, the d->file structure appears to have no
>> characters available to read. There is a statement _Num =
>> _Myios::rdbuf()->in_avail() that sets _Num to zero because deep in
>> the streambuf code's _Gnavail() routine _IGcount points to a zero
>> value. Looking at the code and comment, it seems that _IGcount stores
>> the number of available elements in the read buffer. Note that I
>> changed the call to readsome() to a call to _Readsome_s() to avoid
>> warnings, but readsome() calls _Readsome_s() directly anyway, so it
>> shouldn't make any difference. And I tried it with readsome() as well,
>> and it exhibited seemingly identical behaviour.
>>
>> 3. Comparing d->buffer and d->file after step 1 above, d->file doesn't
>> seem to have the same data in its buffer that d->buffer does. Maybe
>> it's not supposed to?
>>
>> Sorry, all that seems quite obscure, but that's where I've go to.
>>
>> I probably ought to try this on MinGW to see if it works there.
>> Unfortunately that won't help me, as I'm trying ultimately to "fix" a
>> Windows COM dll.
>>
>>
>>>> The argv[1] would have gone unnoticed, but I tried it first with
>>>> the --info
>>>> argument. I was convinced I had some seriously deep bug, started
>>>> debugging,
>>>> and only got suspicious down in libwps::StorageIO::load(), where the
>>>> bufsize
>>>> = buf.tellg() statement returned 0xFFFFFFFF.
>>>>
>>>> Should it have tripped out somewhere before then with a
>>>> non-existent file
>>>> error?
>>>
>>> Hmm, I guess I need to modify POLE to behave gracefully in case the
>>> file does not exist (or tellg returns bogus value). But in the mean
>>> time, I think you can add the sanity check first before feeding the
>>> filename to the stream.
>>
>> Yes, I'll check and not pass an obviously bad filename. In the indexer
>> application it shouldn't be a problem: the string with the filename in
>> it has come from a search of the filesystem.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Libwpd-devel mailing list
> Libwpd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libwpd-devel
- --
Please avoid sending me Word, Excel or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGFsFIu9a1imXPdA8RAk2rAJ9paZNFsFKPKsGA0vB7BK3aPyQSbwCfViSZ
LkZrFDmSmOiku887mft3tI4=
=B63i
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libwpd-devel mailing list
Libwpd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libwpd-devel
