[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with ASSOC,/PACKED
- Subject: Re: Problem with ASSOC,/PACKED
- From: davidf(at)dfanning.com (David Fanning)
- Date: Wed, 1 Mar 2000 05:22:58 -0700
- Newsgroups: comp.lang.idl-pvwave
- Organization: Fanning Software Consulting
- References: <38BB9FFE.C081F10D@phys.ucalgary.ca>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:18730
Brian Jackel (firstname.lastname@example.org) writes:
> I've run across a bug(?) using ASSOC,/PACKED
> This appears under v5.3 for Win9x, and v5.2 on
> If anyone has spare time, could you look
> at the following demonstration script to see if
> I'm doing anything obviously wrong. Tests
> on other architectures or versions would also
> be welcome.
This is the first time I've run across this new
PACKED keyword, so I really couldn't tell you
how it works. But on the face of it (and given
12+ years reading IDL documentation) this appears
to be an unfortunate explanation in the documentation.
I don't have much to go on except a little voice in
my head that goes, "Naaah, that's not how it works."
Here is what I think is happening. I think the PACKED
keyword is for reading data structures that have been
packed one byte after the other into a file, rather
than following the normal structure output rules, which
often result in adding bytes here and there to make
fields align with memory boundaries. This kind of
packing may occur, for example, if the user didn't
write the actual structure, but each *field* of the
structure one after the other.
In any case, when IDL *writes* a structure to a file
it *certainly* follows the usual structure rules,
and there will be added bytes here and there. So
the chances of reading a structure written by IDL
back using the PACKED keyword would, I believe,
almost never work with a real structure with
many fields. I think you are proving this conjecture
with your example.
The statement that using PACKED "acts like READU"
sounds like a technical writer translating a concept
he got from an engineer without fully understanding
the implications of that statement to a user.
I'd follow the usual take-what-you-get-with-a-grain-of-salt
rule here. But I would be willing to bet a couple of
bucks I'm pretty close to being right. :-)
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: email@example.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155