Re: [AD] Reading an allegro packed file directly from a datafile returns incorrect values

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-06-21, Jay Bernardo <allegrolist@xxxxxxxxxx> wrote:
> I believe I have found an issue with the packfile routines and  
> datafiles.  According to the documentation, what I'm trying to do  
> should be perfectly possible. Let me explain the situation.
> 
> Version of Allegro: 4.2.0. Using PACKFILE/pack_fopen/pack_iputl I am  
> writing some data to a file, packed (mode "wp"). I am then putting  
> this file into a datafile with the grabber tool, as binary data. When  
> I try to read this file from the datafile directly, however, the  
> results I get back during reads are complete garbage. I'm reading in  
> the file using PACKFILE/pack_fopen/pack_igetl with a mode of "rp"  
> using the magical notation (e.g., "datafile.dat#object").
> 
> I have noticed that if I generate a file without the pack mode this  
> all works perfectly fine. Either this is a bug, or reading files  
> (that are packed) directly from a datafile is invalid. I'm not sure  
> which. For the record, the datafile is using no compression. I have  
> attached a set of test programs you can use to verify the issue.

The 'p' modifier does not refer to whether the #objects are packed or
not.  In fact, the 'p' modifier is ignored when file#object syntax is
used.  The documentation is not clear, and I'm not sure what the
intended behaviour ought to be.

> fileMaker.c will simply generate a file named "file" that is written  
> with mode "wp" and should contain the value "123" written using  
> pack_iputl.
> fileReader.c will open the packed file in mode "rp" and print the  
> contents to the screen
> datafileReader.c will open the file "datafile.dat#file" and print the  
> contents to the screen
> 
> Within the tarball you'll also find the pre-existing datafile that I  
> used for my own testing, as well as the original file written by  
> fileReader. I suggest trying the ones I have generated as well as  
> versions manually generated. If it's of any use, the junk value I get  
> when attempting to read the 123 from the file is: 560491635

It turns out to be "slh!" in little-endian, i.e. it is reading the
compressed data block without decompressing.

Can I suggest using zip files instead of datafiles?

Peter