On 08/09/13 15:22, JimJoyce wrote:
> 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..
The C compiler is allowed some leeway. I'm not even sure if it is
required to keep the struct elements in the same order (there was a gcc
option to allow it to change the order in certain circumstances, but I
gather it has now been removed since it worked badly with LTO) - it just
has to produce code that /acts/ as though the order is as given.
In particular, the compiler will normally pad elements in a struct as
necessary to fit the alignment requirements of your architecture. On
some architectures, incorrect alignment will mean the program does not
work - it will either work with incorrect data, or trip a processor
exception. On others, incorrect alignment will merely mean the code
runs slowly.
When you are concerned about the exact format of your structs, I
strongly recommend using the "-Wpadded" switch so that the compiler will
inform you of any added padding bytes. Then you can adapt your struct
to fit - possibly by adding explicit "padding" entries to make
everything fit correctly.
David
>
> 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>
>>
>
>
>
