<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>#pragma pack(n) scope</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/27828/pragma-pack-n-scope</link><description> 
Does #pragma pack(n) apply to all the structures in a source code
or it has to be applied to each structure separately ? 
It&amp;#39;s not clear from the manual. 
In one place it says: 
&amp;quot;You can use #pragma pack(n) to make sure that any structures 
with unaligned</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/152184?ContentTypeID=1</link><pubDate>Mon, 02 May 2011 06:55:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:423744b0-d3ba-4edf-afc5-7ddc1a38a5c8</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Andy and Per,&lt;/p&gt;

&lt;p&gt;
Many thanks for your helps.&lt;/p&gt;

&lt;p&gt;
I will do some more study on this.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/151420?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 23:26:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:239cfc31-1437-4040-b38d-158611fd666f</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;It doesn&amp;#39;t!&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
For external transmission &lt;i&gt;on the communication medium&lt;/i&gt;, it
also doesn&amp;#39;t cover the issues of byte ording, data representation,
etc,...&lt;/p&gt;

&lt;p&gt;
So, one more time:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;serialization is&lt;/i&gt; &lt;b&gt;not&lt;/b&gt; &lt;i&gt;a valid rationale for
packing structures&amp;quot;&lt;/i&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/150800?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 23:22:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:22d18f9c-eadf-421e-9553-4a05293acc7f</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;It doesn&amp;#39;t!&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
When used &lt;i&gt;&lt;b&gt;internally&lt;/b&gt;&lt;/i&gt; - within a program - there is
no data alignment problem: the compiler will consistently use the
same alignment rules, so there is &lt;b&gt;&lt;i&gt;no&lt;/i&gt; problem!&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
The problem is that you are trying to use this structure to
represent the format of data sent &lt;i&gt;&lt;b&gt;externally&lt;/b&gt;&lt;/i&gt; to the
program - on the communication medium. So the solution to this is
simple: &lt;b&gt;don&amp;#39;t do that!&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s been mentioned before: the process of taking the information
out of the program&amp;#39;s &lt;i&gt;internal&lt;/i&gt; representation (with its
specific padding, alignment, byte-order, data representation, etc)
and turning it into the required external format for transmission
&lt;i&gt;on the communication medium&lt;/i&gt; is known as
&lt;b&gt;Serialisation&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://en.wikipedia.org/wiki/Serialization"&gt;en.wikipedia.org/.../Serialization&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Hans-Bernhard Broeker said,&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;serialization is &lt;b&gt;not&lt;/b&gt; a valid rationale for packing
structures&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The reverse process - receiving data from the communication medium
and formatting it into the system&amp;#39;s own internal representation - is,
naturally enough, referred to a &lt;b&gt;&lt;i&gt;Deserialisation&lt;/i&gt;&lt;/b&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/146689?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 22:58:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b863c861-875d-4ba6-b837-3fd3246e468b</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The protocol layer may specify big endian. And not only that - the
standard does define the location of the different bits.&lt;/p&gt;

&lt;p&gt;
For a normal PC-class program, that normally just means that an
IPv4 address stored in a 32-bit integer must be processed with
htonl() and ntohl() to make sure that the number ends up as the
expected &amp;lt;n&amp;gt;.&amp;lt;n&amp;gt;.&amp;lt;n&amp;gt;.&amp;lt;n&amp;gt;.&lt;/p&gt;

&lt;p&gt;
But in the end, it&amp;#39;s up to the driver layer and the
compiler/library to make sure that you get valid structure data.&lt;/p&gt;

&lt;p&gt;
In your example, ip_hl and ip_v fits in a single byte. So if you
look, everything but the 8-bit fields are already 16-bit aligned. And
there are 12 bytes when you reach the two structures so they are
32-bit aligned.&lt;/p&gt;

&lt;p&gt;
The network card sends out the data byte-by-byte. So an 8-bit
field isn&amp;#39;t a problem to send and receive on the other end. It&amp;#39;s
fields that are larger than a single byte that are problematic since
the network card can send them out byte-by-byte but the meaning of
the high and low bytes can be swapped. That is why the standard have
defined a &amp;quot;network byte order&amp;quot; and you have functions to perform
conditional byte-reversals of 16-bit and 32-bit integers. So the code
calls these functions without knowing if any byte-reversal will take
place or not - the runtime library will do the required work.&lt;/p&gt;

&lt;p&gt;
But no byte swap is needed for an array of bytes - and your
examples can be seen as two arrays of two bytes each.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/145096?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 22:29:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c27f7200-d7a7-428b-9f32-a86396d91634</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Per,&lt;/p&gt;

&lt;p&gt;
Many thanks for your reply.&lt;/p&gt;

&lt;p&gt;
How about the below example?&lt;br /&gt;
&lt;a href="http://en.wikipedia.org/wiki/Ip_%28struct%29"&gt;en.wikipedia.org/.../Ip_(struct)&lt;/a&gt;&lt;/p&gt;

&lt;pre&gt;
struct ip {
   unsigned int   ip_hl:4; /* both fields are 4 bits */
   unsigned int   ip_v:4;
   &lt;b&gt;uint8_t        ip_tos;&lt;/b&gt;
   uint16_t       ip_len;
   uint16_t       ip_id;
   uint16_t       ip_off;
   &lt;b&gt;uint8_t        ip_ttl;&lt;/b&gt;
   &lt;b&gt;uint8_t        ip_p;&lt;/b&gt;
   uint16_t       ip_sum;
   struct in_addr ip_src;
   struct in_addr ip_dst;
};
&lt;/pre&gt;

&lt;p&gt;
I remember that, all of the protocol layers in the TCP/IP suite
are defined to be big endian.&lt;/p&gt;

&lt;p&gt;
But I just can&amp;#39;t understand how the &lt;b&gt;struct ip&lt;/b&gt; handles data
alignment problem.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/142884?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 21:49:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b33e4eb2-1bd5-4251-a868-87f3ea14d45c</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Note that this is yet one other problem with raw binary transfer
that doesn&amp;#39;t have anything to do with align, padding, ... of
structures.&lt;/p&gt;

&lt;p&gt;
In your example, they have problems with bit fields. They did make
sure that they consumed all 16 bits just to avoid the problem with
where the compiler would place any padding. But since the bit field
container was larger than one byte, different architectures would
still manage to have different byte orders and hence introduce a
difference in the order of the bit fields.&lt;/p&gt;

&lt;p&gt;
So:&lt;br /&gt;
1) Compiler vendors can get away with it, but no one else should
really try to transfer bit field containers larger than 8 bits as raw
containers between different architectures. Bit fields can work quite
well internally, but they were never intended to be shared.&lt;/p&gt;

&lt;p&gt;
2) As already noted: it&amp;#39;s way better to write code to pack/unpack
structures than to fight with manual padding, pragmas etc. Besides
the padding issues, there is also the question of byte orders for
different data types. And the fact that many of the classical C data
types can be different size on different architectures. Today, most
machines have the &amp;quot;standard&amp;quot; two-complement format for integers,
allowing us simple pack/unpack for integers. But it gets worse for
floating point - especially when some targets emulates floating point
and then maybe don&amp;#39;t use the ISO-standardized formats for float and
double.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/139917?ContentTypeID=1</link><pubDate>Sun, 01 May 2011 19:30:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:67414723-ca5b-40ac-85f0-1067a8a7e13e</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Sorry for my limited technical ability and English ability, but I
still hope to take this opportunity to learn more.&lt;/p&gt;

&lt;p&gt;
I did something stupid long ago.&lt;/p&gt;

&lt;pre&gt;
struct UART_Packet {
        char Start1;
        char Start2;
        char FromAddress;
        char ToAddress;
        char String[PACKET_SIZE-10];
        &lt;b&gt;int CRC32;&lt;/b&gt;
        char End1;
        char End2;
};

union {
        struct UART_Packet PacketBUF;
        char StringBUF[PACKET_SIZE];
} UART_Unit_RX, UART_Unit_TX;
&lt;/pre&gt;

&lt;p&gt;
And encountered some data align problem.&lt;br /&gt;
So I changed my struct to:&lt;/p&gt;

&lt;pre&gt;
struct UART_Packet {
        char Start1;
        char Start2;
        char FromAddress;
        char ToAddress;
        char String[PACKET_SIZE-10];
        &lt;b&gt;char CRC32[4];&lt;/b&gt;
        char End1;
        char End2;
};

union {
        struct UART_Packet PacketBUF;
        char StringBUF[PACKET_SIZE];
} UART_Unit_RX, UART_Unit_TX;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
It has been working well (?), since then.&lt;/p&gt;

&lt;p&gt;
After reading the thread, I realized that, there might be some
more problems hidden.&lt;br /&gt;
So I tried to find a better packet format definition defined in C
language.&lt;br /&gt;
&lt;b&gt;I found the following links, and got very confused.&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://en.wikipedia.org/wiki/Tcphdr"&gt;en.wikipedia.org/.../Tcphdr&lt;/a&gt;&lt;br /&gt;

&lt;a href="http://en.wikipedia.org/wiki/Ip_%28struct%29"&gt;en.wikipedia.org/.../Ip_(struct)&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
How do we use these popular packet format definitions
properly?&lt;br /&gt;
I mean, how to handle the data align issue, and other issues that I
don&amp;#39;t really understand, with such C struct definitions.&lt;/p&gt;

&lt;pre&gt;
struct tcphdr {
        unsigned short source;
        unsigned short dest;
        unsigned long seq;
        unsigned long ack_seq;
        #  if __BYTE_ORDER == __LITTLE_ENDIAN
        unsigned short res1:4;
        unsigned short doff:4;
        unsigned short fin:1;
        unsigned short syn:1;
        unsigned short rst:1;
        unsigned short psh:1;
        unsigned short ack:1;
        unsigned short urg:1;
        unsigned short res2:2;
        #  elif __BYTE_ORDER == __BIG_ENDIAN
        unsigned short doff:4;
        unsigned short res1:4;
        unsigned short res2:2;
        unsigned short urg:1;
        unsigned short ack:1;
        unsigned short psh:1;
        unsigned short rst:1;
        unsigned short syn:1;
        unsigned short fin:1;
        #  endif
        unsigned short window;
        unsigned short check;
        unsigned short urg_ptr;
};
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/139914?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 12:29:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:118e685c-a5fe-48e5-ba50-a690d33902e8</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;the assumption that structures on both ends will have the same
data alignment&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That assumption should alsways be assumed to be wrong.&lt;/p&gt;

&lt;p&gt;
In a nutshell, C data structures are for internal use of the C
program. They are generally unsuitable to define any external
interface data, and any attempts to abuse them causes problems you
just don&amp;#39;t need.&lt;/p&gt;

&lt;p&gt;
There&amp;#39;s a reason no self-respecting data interchange format is
defined in terms of C structs: it simply wouldn&amp;#39;t work. Those things
are defined in terms of bits, octets and similarly universal items
for a reason.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/139912?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 10:24:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:07664b8a-34db-4de6-9680-efc6d2bda646</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
That is not an assumption that you should ever even think about
making!&lt;/p&gt;

&lt;p&gt;
Even if you do happen to have a case where it is known (not
assumed) that the two ends do just happen to have the same data
alignment, it is probably still better to design as if they
didn&amp;#39;t.&lt;/p&gt;

&lt;p&gt;
If you rely upon it now, it is bound to change - and it will
certainly be much harder to redesign everything retrospectively than
it would have been to just do it &amp;quot;right&amp;quot; in the first place.&lt;/p&gt;

&lt;p&gt;
And, again, remember that alignment is not the only issue...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/136477?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 10:18:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:66434131-d323-4677-924a-57d6c1ab6132</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;In the end you&amp;#39;ll typically pay more in terms of hassle and
CPU cycles by working with an always packed structure than you would
by packing the data for transport only&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Been there; done that - never again!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;serialization is &lt;b&gt;not&lt;/b&gt; a valid rationale for packing
structures&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Agreed.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/136478?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 09:38:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5dfaa983-c4bc-44a3-9ccf-29e753b65a39</guid><dc:creator>Genp</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;serialization is &lt;b&gt;not&lt;/b&gt; a valid rationale for packing
structures&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
thank you.&lt;br /&gt;
i agree.&lt;br /&gt;
And what is your opinion about the assumption that structures on both
ends will have the same data alignment ?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/126817?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 09:07:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:50582081-6cf3-4506-8934-e2a9c20a4a17</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;2. Pack the structure and send it as a whole.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
This is about the most popular &lt;b&gt;wrong&lt;/b&gt; reason why people
decide to pack structures.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s wrong because you&amp;#39;re only looking at one single aspect of
that data structure&amp;#39;s usage: sending it over the wire. But how do
those data get into that structure? What else are you doing with it?
In the end you&amp;#39;ll typically pay more in terms of hassle and CPU
cycles by working with an always packed structure than you would by
packing the data for transport only. For starters you&amp;#39;ll have to
ensure that every single pointer ever accessing any element of that
packed structure has the &amp;quot;packed&amp;quot; attribute, too. This tends to
spread the hassle and waste of CPU all across the program.&lt;/p&gt;

&lt;p&gt;
And that&amp;#39;s before you consider other transformations you may have
to do at the interface to the outside world anyway (endianness,
floating point format, bit field layout, ...). Those would kill the
idea of &amp;quot;send it as it is&amp;quot; anyway, and remove what little advantage a
packed structure might seem to have.&lt;/p&gt;

&lt;p&gt;
The morale: serialization is &lt;b&gt;not&lt;/b&gt; a valid rationale for
packing structures.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/116349?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 08:16:16 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8fe637c2-d5c3-4df7-8165-b7d92aa3315a</guid><dc:creator>Genp</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;you rather certainly do &lt;b&gt;not&lt;/b&gt; want to do that&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I completely agree and trying to avoid it if possible.&lt;br /&gt;
But let&amp;#39;s consider the following scenario:&lt;br /&gt;
I need to send a rather large (6KB) structure with mixed data types
over the transmission channel. The structure should be reconstructed
on the receiver end.&lt;/p&gt;

&lt;p&gt;
Possible solutions:&lt;br /&gt;
1. Extract all the data fields into continuous buffer and send it,
then do the reverse operation on the receiver&amp;#39;s end. But it&amp;#39;s quite
cumbersome.&lt;br /&gt;
2. Pack the structure and send it as a whole. The structure on the
other end also should be packed.&lt;br /&gt;
3. Send the unpacked structure as a whole, and have a structure on
the other end also unpacked. This is the way I would prefer. But how
certain can I be that both the sent and reconstructed structures have
exactly the same data alignment (both controllers are of the same
type and the same toolset is used for both controllers) ?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/104822?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 06:37:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f48e6065-4c73-43d1-8ac8-3f46a31c4517</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;it will apply to all the structures in a module, right&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It would indeed. Which is why you rather certainly do &lt;b&gt;not&lt;/b&gt;
want to do that. Too many people believe that #pragma pack were a
good idea altogether. It&amp;#39;s not. You&amp;#39;re buying a minimal advantage in
data size for the price of some serious problems in data handling,
not the least of which is a waste of CPU cycles.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/79272?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 05:01:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e7841282-dd69-4126-ba3f-368846a2dfc7</guid><dc:creator>Genp</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you,&lt;br /&gt;
so if it will be the only one at the beginning of a module, it will
apply to all the structures in a module, right ?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: #pragma pack(n) scope</title><link>https://community.arm.com/thread/59397?ContentTypeID=1</link><pubDate>Sat, 30 Apr 2011 00:16:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7ce83554-eaf3-4979-9fac-4bd59e6ab6ef</guid><dc:creator>IB Shy</dc:creator><description>&lt;p&gt;&lt;p&gt;
It applies until any subsequent &lt;i&gt;pragma pack(n)&lt;/i&gt; directive
within the file is encountered.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>