[jsword-devel] Module Format

[Joe Walker]

Still in zverse.cpp, line 161 the logic (whilst technically correct) is 
backwards, compared to the checks made everywhere else in the file, are 
you interested in fixes for this sort of thing?

In place of:

    long newOffset = lseek(compfp[testmt-1]->getFd(), idxoff, SEEK_SET);
    if (newOffset == idxoff) {
        if (read(compfp[testmt-1]->getFd(), &ulBuffNum, 4) != 4) {
            printf ("Error reading ulBuffNum\n");
            return;
        }
    }
    else return;

It could be re-written more like:

    long newOffset = lseek(compfp[testmt-1]->getFd(), idxoff, SEEK_SET);
    if (newOffset != idxoff)
    {
        // maybe we should printf ("Error seeking\n");
        return;
    }

    if (read(compfp[testmt-1]->getFd(), &ulBuffNum, 4) != 4)
    {
         printf ("Error reading ulBuffNum\n");
         return;
     }

And it would fit in a whole lot more with the rest of the file.

Joe.

Joe Walker wrote:

>
> Thanks, I'd not even seen the %.
>
> I remember something like 7 years ago when I moved from C to Java 
> feeling like everything looked the same, but for some reason I 
> couldn't feel the ground under my feet any more. I guess I'm just 
> having to learn to think in memory maps again.
>
> There are just so many things like multi-value return types and 
> pointer arithmetic that make this conversion hard. It'll be good when 
> I can get back up to speed again.
>
> Joe.
>
> Troy A. Griffitts wrote:
>
>> :)
>> Joe,
>>    The individual who initially wrote the compressed drivers chose to 
>> use different file names depending upon the BLOCKTYPE of the 
>> compression.  The files that you mention that end in bz* are 
>> basically saying that the indecies are BOOK oriented (an entry of the 
>> top level index will identify a compressed block of 1 Bible book) , 
>> although the best place to determine this is from the .conf file.
>>
>> The declaration and use of the mechanisms, in the code, is in two parts:
>>
>> Near the top of zVerse you will find the construct:
>>
>> const char zVerse::uniqueIndexID[] = {'X', 'r', 'v', 'c', 'b'};
>>
>> Then index names are built with something like this excerpt from the 
>> code:
>>
>> sprintf(buf, "%s/ot.%czs", path, uniqueIndexID[blockType]);
>>
>> remember %c means CHARACTER, which is replaced by the value of the 
>> param passed (which, I'm sure you knew, but I admit '%czs' does seem 
>> to make the eye just see the CZS as a unit)
>>
>> Hope this helps,
>>        -Troy.
>>
>>
>>
>> Joe Walker wrote:
>>
>>>
>>> Hi,
>>>
>>> My copy of the RSV module contains files with the extension bz* and 
>>> not cz* as read by zVerse.cpp, and I can't find the string bzs in 
>>> the source anywhere that makes sense. What am I doing wrong?
>>>
>>> I've spent hours and hours digging through the C source, and either 
>>> my C is very rusty or it is even harder that I imagined to convert C 
>>> with lots of memory/pointer manipulation into Java. Could anyone 
>>> explain the file format of the GZIP compressed modules? My head 
>>> hurts and I'm not making much progress at the moment. Actually doing 
>>> the decompression is easy - it's reading an array of bytes from disk 
>>> that I am struggling with.
>>>
>>> Thanks,
>>>
>>> Joe.
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel