[Proj] NAD problems on OSX 10.5 Leopard

[William Kyngesburye]

On Jan 15, 2008, at 10:42 PM, Frank Warmerdam wrote:

> William,
>
> I believe the difference is in alignment within the structure between
> 32bit and 64bit systems.  Because the memory image of the structure is
> dumped to disk, the file access is very sensitive to differences in
> how fields are packed into structures in memory.  This can vary based
> on many things.
>
> Really, my preference would be to completely get rid of nadcon style
> binary files in favor of NTv1 or NTv2 style files which are platform
> independent but doing so would require more work than I'm willing
> to invest at this time.
>
> In the meantime, I imagine it would not be too hard to alter the  
> nadcon
> reading and writing functions to use some sort of consistent binary
> file.  But I'm even to lazy to attempt that just now.

Ah, the extra bytes are pointer for the *cvs part of the CTABLE  
structure?

   fwrite(ct.cvs, tsize, 1, stdout)


Or is it written as part of the &ct fwrite?

   fwrite(&ct, sizeof(ct), 1, stdout)

How about:

   fwrite(ct.id, sizeof(ct.id), 1, stdout)
   fwrite(ct.ll, sizeof(ct.ll), 1, stdout)
   fwrite(ct.del, sizeof(ct.del), 1, stdout)
   fwrite(ct.lim, sizeof(ct.lim), 1, stdout)

This way it skips the pointer part of ct.cvs.


On the other side, though, with the current extra bytes, the fseek()  
in nad_ctable_load() doesn't seem to be skipping over those bytes, so  
they are read as part of the data.  Could it be due to sizeof(ct) used  
in nad2bin, but sizeof(struct CTABLE) used in nad_ctable_load()?  Or  
an fseek bug?


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe