1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] GCC3
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20GCC3&In-Reply-To=3c7b236e.01202%40achurch.org">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000329.html">
11 <LINK REL=
"Next" HREF=
"000349.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices Coding] GCC3
</H1>
16 <A HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20GCC3&In-Reply-To=3c7b236e.01202%40achurch.org"
17 TITLE=
"[IRCServices Coding] GCC3">griever at t2n.org
19 <I>Mon Feb
25 22:
18:
47 PST
2002</I>
21 <LI>Previous message:
<A HREF=
"000329.html">[IRCServices Coding] GCC3
23 <LI>Next message:
<A HREF=
"000349.html">[IRCServices Coding] GCC3
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#330">[ date ]
</a>
27 <a href=
"thread.html#330">[ thread ]
</a>
28 <a href=
"subject.html#330">[ subject ]
</a>
29 <a href=
"author.html#330">[ author ]
</a>
34 <PRE>On Tue,
26 Feb
2002, Andrew Church wrote:
36 ><i> >Reordering is not permitted by the ANSI/ISO C standards.
38 </I>><i> That's what I thought, but a whole bunch of people seemed to think GCC
39 </I>><i> 3.0 was doing just that.
41 </I>><i> >> struct foo
42 </I>><i> >> {
43 </I>><i> >> int_16 bar;
44 </I>><i> >> int_8 baz;
45 </I>><i> >> };
47 </I>><i> >> The compiler would append or prepend (depending on compiler)
48 </I>><i> >> on an extra
40bits of data to align it in memory on each
49 </I>><i> >> allocation.
51 </I>><i> >Under
32bit x86, it's likely to add
8 bits of padding to the end
52 </I>><i> >of the structure. The alignment is for the width of the largest
53 </I>><i> >datatype.
55 </I>><i> Again, that's what I thought--compilers aren't supposed to pad more
56 </I>><i> than the largest type in the structure, and between structure members only
57 </I>><i> enough to align the next member to a multiple of its size. I'm pretty sure
58 </I>><i> this is defined somewhere, and if not then it should be (see below).
59 </I>Not the largest type in the structure, the largest *type*.
60 Most structures will pad to
32 bits on intel machines.
66 /* inserts
8 or
24 bits of padding here */
68 /* inserts
16 bits of padding here */
74 </I>><i> >Partly for this reason, mapping structs onto arbitrary data in
75 </I>><i> >memory results in undefined behavior.
77 </I>><i> It shouldn't, and if it did things would break all over the place.
78 </I>><i> Suppose you have two compilers, one of which is used to compile a program,
79 </I>><i> and the other of which is used to compile a library used by the program.
80 </I>><i> Now suppose the program passes a pointer to a structure (say, a FILE *) to
81 </I>><i> the library. If the two compilers use different algorithms to pad
82 </I>><i> structure members, guess what happens? Boom.
84 </I>IF I remember correctly, POSIX mandates uniform structure padding
85 for all compilers on a single platform.
87 ><i> --Andrew Church
88 </I>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A>
89 </I>><i> <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
90 </I>><i> ------------------------------------------------------------------
91 </I>><i> To unsubscribe or change your subscription options, visit:
92 </I>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
</A>
102 <LI>Previous message:
<A HREF=
"000329.html">[IRCServices Coding] GCC3
104 <LI>Next message:
<A HREF=
"000349.html">[IRCServices Coding] GCC3
106 <LI> <B>Messages sorted by:
</B>
107 <a href=
"date.html#330">[ date ]
</a>
108 <a href=
"thread.html#330">[ thread ]
</a>
109 <a href=
"subject.html#330">[ subject ]
</a>
110 <a href=
"author.html#330">[ author ]
</a>
projects / irc.git / blob