I am having a problem with reading a C written binary file with IDL.
It may come from differences of type definitions between C and IDL but
I could not really figure out from Google...
In C, it writes a structure containing the following variable types:
struct MyStruct
{
int a;
long long b;
int c;
float d;
};
Then, in IDL, I read this with:
MyStruct = {$
a : 0L, $
b : 0LL, $
c : 0L, $
d : 0.0 $
}
This is because C pads the structure to produce alignments. Under
'normal' operations, you would expect MyStruct to be 20 bytes,
however, if you do a sizeof(struct MyStruct), you will probably see
that the size is 24. (And you can enable the warning for gcc by using
the compile time option -Wpadded).
In general, the padding is compiler specific -- so there is no
standard way of reading in those binary files into IDL/other codes.
The best bet would be to write out the individual fields of the
structure and then read them back into IDL.
HTH,
Manodeep
On Feb 9, 9:44 pm, bing999 <thibaultga...@gmail.com> wrote:
> I am having a problem with reading a C written binary file with IDL.
> It may come from differences of type definitions between C and IDL but
> I could not really figure out from Google...
> In C, it writes a structure containing the following variable types:
> struct MyStruct
> {
> int a;
> long long b;
> int c;
> float d;
> };
> Then, in IDL, I read this with:
> MyStruct = {$
> a : 0L, $
> b : 0LL, $
> c : 0L, $
> d : 0.0 $
> }
Have you tried ASSOC? It has a PACKED keyword you can play with:
<quote>
PACKED
When ASSOC is applied to structures, the default action is to map the actual definition of the structure for the current
machine, including any holes required to properly align the fields. (IDL uses the same rules for laying out structures
as the C language). If the PACKED keyword is specified, I/O using the resulting variable instead works in the same
manner as READU and WRITEU, and data is moved one field at a time and there are no alignment gaps between the fields.
</quote>
So you might want to experiment with ASSOC and /PACKED, e.g.
mystruct={a:0L, b:0LL, c:0L,d:0.0}
openr, 1, filename, /swap_if_big_endian
a = assoc(1, {a:0L, b:0LL, c:0L,d:0.0})
or
a = assoc(1, {a:0L, b:0LL, c:0L,d:0.0},/packed)
help, a[0]
> I am having a problem with reading a C written binary file with IDL.
> It may come from differences of type definitions between C and IDL but
> I could not really figure out from Google...
> In C, it writes a structure containing the following variable types:
> struct MyStruct
> {
> int a;
> long long b;
> int c;
> float d;
> };
> Then, in IDL, I read this with:
> MyStruct = {$
> a : 0L, $
> b : 0LL, $
> c : 0L, $
> d : 0.0 $
> }
On Feb 9, 11:56 pm, Manodeep Sinha <manod...@gmail.com> wrote:
> Hi,
> This is because C pads the structure to produce alignments. Under
> 'normal' operations, you would expect MyStruct to be 20 bytes,
> however, if you do a sizeof(struct MyStruct), you will probably see
> that the size is 24. (And you can enable the warning for gcc by using
> the compile time option -Wpadded).
The N_TAGS() function has LENGTH and DATA_LENGTH keywords:
Bill Nel wrote:
> On Feb 9, 11:56 pm, Manodeep Sinha <manod...@gmail.com> wrote:
>> Hi,
>> This is because C pads the structure to produce alignments. Under
>> 'normal' operations, you would expect MyStruct to be 20 bytes,
>> however, if you do a sizeof(struct MyStruct), you will probably see
>> that the size is 24. (And you can enable the warning for gcc by using
>> the compile time option -Wpadded).
> The N_TAGS() function has LENGTH and DATA_LENGTH keywords:
First, as the issue seems to be more complicated than i first thought,
i have to say that the structure i have to read is bigger than what I
wrote previously just to make an example.
It actually contains (in the right order):
int x 1
long long x 1
int x 5
float x 9
int x 1
float x 24
that is, 7 int, 33 float and 1 long long (written in C).
When I look at the IDL commands you suggest, i get:
print,n_tags(mystruct,/length) 176
print,n_tags(mystruct,/data_length) 172
So you were right.
Now, the question is "How to handle that?? " :)
I inserted an extra int (0L) in the structure of my IDL reading
routine in second position of the structure (just before the long
long), and it gives results coherent with what one gets with a correct
Python routine. However, I am not quite satisfied with this
solution...
> Bill Nel wrote:
> > On Feb 9, 11:56 pm, Manodeep Sinha <manod...@gmail.com> wrote:
> >> Hi,
> >> This is because C pads the structure to produce alignments. Under
> >> 'normal' operations, you would expect MyStruct to be 20 bytes,
> >> however, if you do a sizeof(struct MyStruct), you will probably see
> >> that the size is 24. (And you can enable the warning for gcc by using
> >> the compile time option -Wpadded).
> > The N_TAGS() function has LENGTH and DATA_LENGTH keywords:
> sorry to reply so late, but I was away recently.
> First, as the issue seems to be more complicated than i first thought,
> i have to say that the structure i have to read is bigger than what I
> wrote previously just to make an example.
> It actually contains (in the right order):
> int x 1
> long long x 1
> int x 5
> float x 9
> int x 1
> float x 24
> that is, 7 int, 33 float and 1 long long (written in C).
> When I look at the IDL commands you suggest, i get:
> print,n_tags(mystruct,/length) 176
> print,n_tags(mystruct,/data_length) 172
> So you were right.
> Now, the question is "How to handle that?? " :)
> I inserted an extra int (0L) in the structure of my IDL reading
> routine in second position of the structure (just before the long
> long), and it gives results coherent with what one gets with a correct
> Python routine. However, I am not quite satisfied with this
> solution...
> Does anyone can think of a better way to proceed?
> Thanks !!
> > Bill Nel wrote:
> > > On Feb 9, 11:56 pm, Manodeep Sinha <manod...@gmail.com> wrote:
> > >> Hi,
> > >> This is because C pads the structure to produce alignments. Under
> > >> 'normal' operations, you would expect MyStruct to be 20 bytes,
> > >> however, if you do a sizeof(struct MyStruct), you will probably see
> > >> that the size is 24. (And you can enable the warning for gcc by using
> > >> the compile time option -Wpadded).
> > > The N_TAGS() function has LENGTH and DATA_LENGTH keywords:
Actually I cannot use assoc i guess. To be fully complete this
time :), the binary file contain a header (some int) + the structure
mystruct which is replicated N times. From what I understand of the
assoc function, it won't work in my case...
And the problem is that i cannot changer the compiling options of the
C code...
> > sorry to reply so late, but I was away recently.
> > First, as the issue seems to be more complicated than i first thought,
> > i have to say that the structure i have to read is bigger than what I
> > wrote previously just to make an example.
> > It actually contains (in the right order):
> > int x 1
> > long long x 1
> > int x 5
> > float x 9
> > int x 1
> > float x 24
> > that is, 7 int, 33 float and 1 long long (written in C).
> > When I look at the IDL commands you suggest, i get:
> > print,n_tags(mystruct,/length) 176
> > print,n_tags(mystruct,/data_length) 172
> > So you were right.
> > Now, the question is "How to handle that?? " :)
> > I inserted an extra int (0L) in the structure of my IDL reading
> > routine in second position of the structure (just before the long
> > long), and it gives results coherent with what one gets with a correct
> > Python routine. However, I am not quite satisfied with this
> > solution...
> > Does anyone can think of a better way to proceed?
> > Thanks !!
> > > Bill Nel wrote:
> > > > On Feb 9, 11:56 pm, Manodeep Sinha <manod...@gmail.com> wrote:
> > > >> Hi,
> > > >> This is because C pads the structure to produce alignments. Under
> > > >> 'normal' operations, you would expect MyStruct to be 20 bytes,
> > > >> however, if you do a sizeof(struct MyStruct), you will probably see
> > > >> that the size is 24. (And you can enable the warning for gcc by using
> > > >> the compile time option -Wpadded).
> > > > The N_TAGS() function has LENGTH and DATA_LENGTH keywords:
bing999 writes: > Actually I cannot use assoc i guess. To be fully complete this
> time :), the binary file contain a header (some int) + the structure
> mystruct which is replicated N times. From what I understand of the
> assoc function, it won't work in my case...
I think your understanding must be faulty, as this
is *exactly* the kind of file ASSOC works best with. :-)
The "offset" is used to account for the header.
Cheers,
David
-- David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
> bing999writes:
> > Actually I cannot use assoc i guess. To be fully complete this
> > time :), the binary file contain a header (some int) + the structure
> > mystruct which is replicated N times. From what I understand of the
> > assoc function, it won't work in my case...
> I think your understanding must be faulty, as this
> is *exactly* the kind of file ASSOC works best with. :-)
> The "offset" is used to account for the header.
> Cheers,
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.idlcoyote.com/ > Sepore ma de ni thui. ("Perhaps thou speakest truth.")
