C Struct Data Problem

[heroin_bob]

Gracious Monks, I'm writing a simple utility to convert 3D vertex information from one file format to another. While reading and parsing the file information I can't seem to figure out why I'm getting very wierd information. For example in a variable that acts as a flag and it's values could be 0-2 it comes in as an arbitrary number in the billions.

Since the file structure is documented as a series of C structs, I tried writing the utility in C which yielded worse results than Perl. At least with Perl I get about 1/4 of the fields back with correct information. Any help or guidance in the right direction would be most appreciated. Here's the code and header structure I'm working with:
*----------- C Code --------------*

struct block1 {
    char version[64];
    char comments[128];
    char dummy[8];            
    long img_param_flag;      
    long img_data_type;       
    float invalid_point;      
    long  arr_width;           
    long  arr_height;          
    long  db_length;           
    long scale;               
    float iscale;             
    float jscale;
    long trns_matrix_f;       
    double trns_matrix[16];   
    long img_color;           
    long clr_blk_length;      
    long cam_pos_f;           
    float cam_x;
    float cam_y;
    float cam_z;
} *blk1;

*----------- Perl Code --------------*

use strict;
use Dumpvalue;
use POSIX;

sub dump_ref  {
    my $ref = shift;
    my $dumper = new Dumpvalue;
    print "Content-Type:text/html\n\n";
    print "<pre>";
    $dumper->dumpValues($ref);
    print "</pre>";
    exit;
}

# read in the 3D info.
# use unpack to parse the structure
my ($block1, $block2);
open(FP, "<./file.pf") || die("Error opening file: $!\n");
binmode(FP);
read(FP, $block1, 512); # 512 byte binary c structure

# Note that the longs are in Network order
my @block1_info = unpack("a64a128a8NNfNNNNffNd16NNNfffN30",$block1);

dump_ref(\@block1_info);
exit;

*UPDATE* Apparently the only one coming in erroneous (in Perl) is the transformation matrix... the array of 16 doubles. I'm getting numbers like "3.03865194161742e-319" and when I apply them to the data I get numbers even smaller. Indices 13-28 is what I'm referring to... it's a 4 X 4 transformation matrix for conversion to another coordinate system. Here's a dump of the info I'm getting back:

0  ARRAY(0x80d54b0)
   0  "PIF Format v2.0"
   1  ""
   2  ""
   3  0
   4  1
   5  0
   6  149
   7  78
   8  139464
   9  0
   10  0
   11  0
   12  2
   13  '3.03865194161742e-319'
   14  0
   15  0
   16  0
   17  0
   18  0
   19  '3.04497598188419e-319'
   20  0
   21  0
   22  '3.03865194161742e-319'
   23  0
   24  0
   25  0
   26  0
   27  0
   28  '3.03865194161742e-319'
   29  1
   30  11622
   31  1
   32  0
   33  0
   34  0
   35  0
   36  0
   37  0
   38  0
   39  0
   40  0
   41  0
   42  0
   43  0
   44  0
   45  0
   46  0
   47  0
   48  0
   49  0
   50  0
   51  0
   52  0
   53  0
   54  0
   55  0
   56  0
   57  0
   58  0
   59  0
   60  0
   61  0
   62  0
   63  0
   64  0

[BrowserUk]

*UPDATE* Apparently the only one coming in erroneous (in Perl) is the transformation matrix... the array of 16 doubles.

What type of system is the data being written on? (And what type of system are you unpacking it on?)

My guess is that they are different types. Whilst the 'N' format will ensure that an integer packed on a big-endian system will be correctly unpacked on a little-endian box, there is no such guarentee for the 'd' (or 'f') formats. From perlfunc:pack:

    f   A single-precision float in the native format.
    d   A double-precision float in the native format.

Even if both source and destination use the same floating point representation, the physical layout of the bytes that make up that representation will vary with endianess.

If this assumption is correct, then the very minimum you would need to do is to re-order the bytes to compensate. This can be done by unpacking your doubles to 8-byte strings and using reverse or similar methods to re-order the bytes before using unpack to decode them. But that will only work if they both use the same basic FP representation.

You'll need to find out what FP reps are used at both ends before progressing.

See Re: Value packed as 'D', how to unpack not using 'D'? and Re: graphic a segy file for related problems.

[heroin_bob]

Thanx BrowserUK, I'll look into this and post my findings

[BrowserUk]

A hex dump of a coupe of blocks would help here.

[trammell]

You could be running into an endianness issue; perhaps instead of N you want V? Which fields are getting garbled?

[heroin_bob]

Sorry Trammell, I updated my post. Apparently it's only the array of 16 doubles that's seemingly garbled...