[Proj] NAD problems on OSX 10.5 Leopard
woklist at kyngchaos.com
Wed Jan 16 00:30:59 EST 2008
On Jan 15, 2008, at 10:42 PM, Frank Warmerdam wrote:
> 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
> 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
fwrite(ct.cvs, tsize, 1, stdout)
Or is it written as part of the &ct fwrite?
fwrite(&ct, sizeof(ct), 1, stdout)
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>
"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
More information about the Proj