]> jfr.im git - irc.git/blob - software/RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2002/000350.html
rename -> *.git
[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2002 / 000350.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2 <HTML>
3 <HEAD>
4 <TITLE> [IRCServices Coding] GCC3
5 </TITLE>
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=397C2F92-2AD3-11D6-8FB8-0003938D6866%40softhome.net">
8 <META NAME="robots" CONTENT="index,nofollow">
9 <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
10 <LINK REL="Previous" HREF="000349.html">
11 <LINK REL="Next" HREF="000331.html">
12 </HEAD>
13 <BODY BGCOLOR="#ffffff">
14 <H1>[IRCServices Coding] GCC3</H1>
15 <B>Finny Merrill</B>
16 <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20GCC3&In-Reply-To=397C2F92-2AD3-11D6-8FB8-0003938D6866%40softhome.net"
17 TITLE="[IRCServices Coding] GCC3">griever at t2n.org
18 </A><BR>
19 <I>Tue Feb 26 12:01:21 PST 2002</I>
20 <P><UL>
21 <LI>Previous message: <A HREF="000349.html">[IRCServices Coding] GCC3
22 </A></li>
23 <LI>Next message: <A HREF="000331.html">[IRCServices Coding] GCC3
24 </A></li>
25 <LI> <B>Messages sorted by:</B>
26 <a href="date.html#350">[ date ]</a>
27 <a href="thread.html#350">[ thread ]</a>
28 <a href="subject.html#350">[ subject ]</a>
29 <a href="author.html#350">[ author ]</a>
30 </LI>
31 </UL>
32 <HR>
33 <!--beginarticle-->
34 <PRE>On Tue, 26 Feb 2002, Trevor Talbot wrote:
35
36 &gt;<i> On Monday, February 25, 2002, at 09:48 PM, Andrew Church wrote:
37 </I>&gt;<i>
38 </I>&gt;<i> &gt;&gt; Reordering is not permitted by the ANSI/ISO C standards.
39 </I>&gt;<i> &gt;
40 </I>&gt;<i> &gt; That's what I thought, but a whole bunch of people seemed to think
41 </I>&gt;<i> &gt; GCC
42 </I>&gt;<i> &gt; 3.0 was doing just that.
43 </I>&gt;<i>
44 </I>&gt;<i> It occurs to me that this has been talked about as a somewhat-useful
45 </I>&gt;<i> optimization. The idea is to reorder struct members for optimal padding.
46 </I>&gt;<i> But even if gcc did adopt this as an extension (I don't know if it does
47 </I>&gt;<i> or
48 </I>&gt;<i> not), it would have to be disabled by default, as several things (such as
49 </I>&gt;<i> ANSI offsetof()) would break.
50 </I>&gt;<i>
51 </I>&gt;<i> &gt; Again, that's what I thought--compilers aren't supposed to pad more
52 </I>&gt;<i> &gt; than the largest type in the structure, and between structure members
53 </I>&gt;<i> &gt; only
54 </I>&gt;<i> &gt; enough to align the next member to a multiple of its size. I'm pretty
55 </I>&gt;<i> &gt; sure
56 </I>&gt;<i> &gt; this is defined somewhere, and if not then it should be (see below).
57 </I>&gt;<i> &gt;
58 </I>&gt;<i> &gt;&gt; Partly for this reason, mapping structs onto arbitrary data in
59 </I>&gt;<i> &gt;&gt; memory results in undefined behavior.
60 </I>&gt;<i> &gt;
61 </I>&gt;<i> &gt; It shouldn't, and if it did things would break all over the place.
62 </I>&gt;<i> &gt; Suppose you have two compilers, one of which is used to compile a
63 </I>&gt;<i> &gt; program,
64 </I>&gt;<i> &gt; and the other of which is used to compile a library used by the program.
65 </I>&gt;<i> &gt; Now suppose the program passes a pointer to a structure (say, a FILE *)
66 </I>&gt;<i> &gt; to
67 </I>&gt;<i> &gt; the library. If the two compilers use different algorithms to pad
68 </I>&gt;<i> &gt; structure members, guess what happens? Boom.
69 </I>&gt;<i>
70 </I>&gt;<i> Actually, I was referring to things such as:
71 </I>&gt;<i>
72 </I>&gt;<i> struct tag {
73 </I>&gt;<i> char type;
74 </I>&gt;<i> uint_32 value;
75 </I>&gt;<i> } *s;
76 </I>&gt;<i>
77 </I>&gt;<i> char map[32];
78 </I>should be unsigned char.
79 &gt;<i>
80 </I>&gt;<i> /* load map with some data */
81 </I>&gt;<i>
82 </I>&gt;<i> s = (struct tag *)map;
83 </I>&gt;<i>
84 </I>&gt;<i> But your point about compilers is a valid one; I don't know about
85 </I>&gt;<i> POSIX (as someone else commented), but in general compilers adopt
86 </I>&gt;<i> the same alignment scheme for a particular architecture. After all,
87 </I>&gt;<i> the architecture is what requires certain alignments anyway :)
88 </I>&gt;<i>
89 </I>&gt;<i> -- Quension
90 </I>&gt;<i>
91 </I>&gt;<i> ------------------------------------------------------------------
92 </I>&gt;<i> To unsubscribe or change your subscription options, visit:
93 </I>&gt;<i> <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A>
94 </I>&gt;<i>
95 </I>
96
97 </PRE>
98
99 <!--endarticle-->
100 <HR>
101 <P><UL>
102 <!--threads-->
103 <LI>Previous message: <A HREF="000349.html">[IRCServices Coding] GCC3
104 </A></li>
105 <LI>Next message: <A HREF="000331.html">[IRCServices Coding] GCC3
106 </A></li>
107 <LI> <B>Messages sorted by:</B>
108 <a href="date.html#350">[ date ]</a>
109 <a href="thread.html#350">[ thread ]</a>
110 <a href="subject.html#350">[ subject ]</a>
111 <a href="author.html#350">[ author ]</a>
112 </LI>
113 </UL>
114
115 </body></html>