Thanks, Jonathan, for your speedy reply.
However, I'm surprised, That 'C' can pad structures as it sees fit.
I thought the point and value of user-defined structures was to suit user's
needs.
not the whim of the compiler..
I think you're telling me that '__attribute__((__packed__))' is what I
need to do to force the compiler to do things my way?
I learned my coding in the old days, using IBM 360 Assembler.
We programmers told the system how we wanted things.
Happy Days !
Thanks, JJ
On 8 September 2013 13:30, Jonathan Wakely-4 [via gcc] <
ml-node+s1065356n966604h15@xxxxxxxxxxxxx> wrote:
> On 8 September 2013 11:10, JimJoycewrote:
> > Is this a bug?
>
> No.
>
> > I'm coding in plain 'C'.
> > I am trying to read and write GIS shapefiles.
> > They start with a header of 9 ints and 8 doubles.
> >
> > So I used a structure eg:
> > struct hdr { int g1[9]; double g2[8] }; struc;
> > fread ( struc, 100, 1, fp1);
> > It was screwing up my doubles.
> > --
> > When, eventually, I experimented:
> > sizeof(g1); sizeof(g2), sizeof (struc).
> > I got 36, 64, 104.
> > Note 104, not 100.
> >
> > Where is gcc placing the redundant 4 bytes?
>
> Between the two arrays. The array of doubles is 8-byte aligned,
> presumably because that's what your architecture requires.
>
> > Is 'struct' insisting on a doubleword boundary?
>
> For the double array, yes. The C standard doesn't say struct members
> must be adjacent, padding is allowed.
>
> > NB I got round the problem by using 2 fread()s
> > fread(struc.g1,36,1,fp1);
> > fread(struc.g2,64,1,fp1);
>
> That's the right thing to do.
>
> You could also try this:
>
> struct __attribute__((__packed__)) hdr { int g1[9]; double g2[8]; };
>
> Although the compiler adds the padding for good reasons so it's best
> not to force it to use a different layout unless you really need to.
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://gcc.1065356.n5.nabble.com/gcc-structures-tp966595p966604.html
> To unsubscribe from gcc structures, click here<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=966595&code=amltQGppbWpveWNlLmNvLnVrfDk2NjU5NXwtOTM4MDcwNDA4>
> .
> NAML<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
JimJoyce
T: 0(044) 1280 813 899
E: jim@xxxxxxxxxxxxxx
--
View this message in context: http://gcc.1065356.n5.nabble.com/gcc-structures-tp966595p966606.html
Sent from the gcc - Help mailing list archive at Nabble.com.
