* Size and pack @ 2001-10-10 8:05 Adrian Hoe 2001-10-10 8:59 ` Alfred Hilscher ` (5 more replies) 0 siblings, 6 replies; 51+ messages in thread From: Adrian Hoe @ 2001-10-10 8:05 UTC (permalink / raw) Hello, I have the following declaration: type Rx_Header_Data is record Start_Byte : Character := Latin_1.STX; Splitter : Character; Command_Byte : Character; Pad_Byte_1 : Character; Pad_Byte_2 : Character; Log_Num : Interfaces.C.Long; End_Byte : Character := Latin_1.ETX; LRC : Character; end record; It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 bytes. 'Size will report 11 bytes when I add the following line: pragma pack (Rx_Header_Data); I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without pragma pack. Why this happens? Can I use representation clause instead of pragma pack? If both methods work, which is the best approach and why? I use GNAT 3.13p on Linux. Thank you. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe @ 2001-10-10 8:59 ` Alfred Hilscher 2001-10-10 9:50 ` John McCabe 2001-10-10 9:24 ` Pi ` (4 subsequent siblings) 5 siblings, 1 reply; 51+ messages in thread From: Alfred Hilscher @ 2001-10-10 8:59 UTC (permalink / raw) I'm not sure, but I think it is because Log_Num would start on an odd adress otherwise, and so there are three bytes left to align it to a word boundary. Yes, shou should be able to do it with rep-spec. Adrian Hoe wrote: > > Hello, > > I have the following declaration: > > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; > Splitter : Character; > Command_Byte : Character; > Pad_Byte_1 : Character; > Pad_Byte_2 : Character; > Log_Num : Interfaces.C.Long; > End_Byte : Character := Latin_1.ETX; > LRC : Character; > end record; > > It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 > bytes. 'Size will report 11 bytes when I add the following line: > > pragma pack (Rx_Header_Data); > > I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without > pragma pack. > > Why this happens? Can I use representation clause instead of pragma > pack? If both methods work, which is the best approach and why? > > I use GNAT 3.13p on Linux. > > Thank you. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:59 ` Alfred Hilscher @ 2001-10-10 9:50 ` John McCabe 2001-10-11 6:36 ` Adrian Hoe 2001-10-31 1:50 ` Robert Dewar 0 siblings, 2 replies; 51+ messages in thread From: John McCabe @ 2001-10-10 9:50 UTC (permalink / raw) On Wed, 10 Oct 2001 10:59:30 +0200, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: Sorry I missed the original post but... >> Why this happens? Can I use representation clause instead of pragma >> pack? If both methods work, which is the best approach and why? Your best bet would be to use as many representation attributes as are necessary. In general I would use both a representation clause and pragma pack on an item such as this, and possibly an alignment clause, to guarantee as much as possible that the record layout in memory is the way that you want it. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 9:50 ` John McCabe @ 2001-10-11 6:36 ` Adrian Hoe 2001-10-11 8:55 ` John McCabe 2001-10-31 1:50 ` Robert Dewar 1 sibling, 1 reply; 51+ messages in thread From: Adrian Hoe @ 2001-10-11 6:36 UTC (permalink / raw) john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>... > On Wed, 10 Oct 2001 10:59:30 +0200, Alfred Hilscher > <Alfred.Hilscher@icn.siemens.de> wrote: > > Sorry I missed the original post but... > > >> Why this happens? Can I use representation clause instead of pragma > >> pack? If both methods work, which is the best approach and why? > > Your best bet would be to use as many representation attributes as are > necessary. In general I would use both a representation clause and > pragma pack on an item such as this, and possibly an alignment clause, > to guarantee as much as possible that the record layout in memory is > the way that you want it. I investigated the memory location of every components in record. The memory location (byte sequences which have been allocated) is of no difference if I applied: 1. pragma pack 2. representation clauses 3. both pragma pack and representation clauses. What kind of assurance the compiler can offer if we use the above approach? What is the portability issue (if any) from a 32-bit to 64-bit processor? Also, if the insertion of unused bytes by the compiler is to optimize, what could it be? Speed or space? Adrian ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 6:36 ` Adrian Hoe @ 2001-10-11 8:55 ` John McCabe 2001-10-31 1:53 ` Robert Dewar 0 siblings, 1 reply; 51+ messages in thread From: John McCabe @ 2001-10-11 8:55 UTC (permalink / raw) On 10 Oct 2001 23:36:46 -0700, byhoe@greenlime.com (Adrian Hoe) wrote: >I investigated the memory location of every components in record. The >memory location (byte sequences which have been allocated) is of no >difference if I applied: > >1. pragma pack >2. representation clauses >3. both pragma pack and representation clauses. > >What kind of assurance the compiler can offer if we use the above >approach? As far as I remember, if a representation clause is supported by the compiler (check it's Annexe M documentation in case it does something odd), it should be guaranteed. >What is the portability issue (if any) from a 32-bit to >64-bit processor? Depends on the compiler. The example earlier... > for rx_header_data_packed use record > start_byte at 0 range 0 .. 7; > splitter at 1 range 0 .. 7; > command_byte at 2 range 0 .. 7; > pad_byte_1 at 3 range 0 .. 7; > log_num at 4 range 0 .. 31; -- Changed > pad_byte_2 at 8 range 0 .. 7; -- Changed > end_byte at 9 range 0 .. 7; > lrc at 10 range 0 .. 7; > end record; Could also be written as: for rx_header_data_packed use record start_byte at 0 range 0 .. 7; splitter at 0 range 8 .. 15; command_byte at 0 range 16 .. 23; pad_byte_1 at 0 range 24 .. 31; log_num at 0 range 32 .. 63; pad_byte_2 at 0 range 64 .. 71; end_byte at 0 range 72 .. 79; lrc at 0 range 80 .. 87; end record; which would remove the possibility of confusion because of different storage unit sizes. Ultimately, despite Ada's famed portability, nothing is 100% guaranteed (especially if you use a different compiler) and you'd be advised to make sure it still looks like it did before on a different machine. >Also, if the insertion of unused bytes by the compiler is to optimize, >what could it be? Speed or space? Generally speed because accesses to 1x whole word is quicker than access to 2x parts of words. However space can come into it, because to access 2x parts of words takes more code than accessing 1x whole word. Whether space is improved depends on how many object of the type you are using and how many different places you are using it. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 8:55 ` John McCabe @ 2001-10-31 1:53 ` Robert Dewar 0 siblings, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 1:53 UTC (permalink / raw) john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc55c38.3322217@news.demon.co.uk>... > Depends on the compiler. The example earlier... > > > for rx_header_data_packed use record > > start_byte at 0 range 0 .. 7; > > splitter at 1 range 0 .. 7; > > command_byte at 2 range 0 .. 7; > > pad_byte_1 at 3 range 0 .. 7; > > log_num at 4 range 0 .. 31; -- Changed > > pad_byte_2 at 8 range 0 .. 7; -- Changed > > end_byte at 9 range 0 .. 7; > > lrc at 10 range 0 .. 7; > > end record; > > Could also be written as: > for rx_header_data_packed use record > start_byte at 0 range 0 .. 7; > splitter at 0 range 8 .. 15; > command_byte at 0 range 16 .. 23; > pad_byte_1 at 0 range 24 .. 31; > log_num at 0 range 32 .. 63; > pad_byte_2 at 0 range 64 .. 71; > end_byte at 0 range 72 .. 79; > lrc at 0 range 80 .. 87; > end record; > > which would remove the possibility of confusion because > of different storage unit sizes. This is FUD, the above rewriting accomplishes nothing and is wholly undesirable. No confusion arises in either case on a byte addressed machine, and on a word addressed machine, neither form is likely to give you what you want. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 9:50 ` John McCabe 2001-10-11 6:36 ` Adrian Hoe @ 2001-10-31 1:50 ` Robert Dewar 2001-10-31 9:17 ` John McCabe 2001-10-31 11:58 ` Jeff Creem 1 sibling, 2 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 1:50 UTC (permalink / raw) john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>... > Your best bet would be to use as many representation attributes as are > necessary. In general I would use both a representation clause and > pragma pack No, that's pointless, if you use a complete rep clause, then it is redundant to use pragma Pack since it won't have any effect. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 1:50 ` Robert Dewar @ 2001-10-31 9:17 ` John McCabe 2001-10-31 11:58 ` Jeff Creem 1 sibling, 0 replies; 51+ messages in thread From: John McCabe @ 2001-10-31 9:17 UTC (permalink / raw) On 30 Oct 2001 17:50:14 -0800, dewar@gnat.com (Robert Dewar) wrote: >john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>... >> Your best bet would be to use as many representation attributes as are >> necessary. In general I would use both a representation clause and >> pragma pack > >No, that's pointless, if you use a complete rep clause, then it is >redundant to use pragma Pack since it won't have >any effect. Interesting you should say that, because it conflicts with your opinion from a previous, very similar comment I made some time ago! It would appear your technical opinions change with the weather! ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 1:50 ` Robert Dewar 2001-10-31 9:17 ` John McCabe @ 2001-10-31 11:58 ` Jeff Creem 2001-11-01 1:58 ` Adrian Hoe ` (2 more replies) 1 sibling, 3 replies; 51+ messages in thread From: Jeff Creem @ 2001-10-31 11:58 UTC (permalink / raw) OK.. I know I am going to regret this since whenever I question Robert I usually am wrong however without using the complete context of this thread, I believe Roberts statement is actually a little too broad. There ARE indeed times when you want a pragma pack and a rep spec. Not for the record case but for arrays of items that have been rep spec'ed. for example, the code fragment type My_Type is range 0 .. 3; for My_Type'size use 2; type My_Array is array (1 .. 4) of My_Type; pragma Pack (My_Array); -- Without this the following could fail for My_Array'size use 8; The pragma pack is needed I believe because the rep spec on My_Array can be rejected without it (At least it has been rejected by some compilers and I forget the exact rule but it had something to do with the final rep spec not being allowed to change the layout of the items within the array). Having said that VADS used to compile this without the pragma pack. Green Hills did not. I *THINK* GNAT does allow it to go through without the rep spec for several versions now. "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0110301750.38ba5bfd@posting.google.com... > john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>... > > Your best bet would be to use as many representation attributes as are > > necessary. In general I would use both a representation clause and > > pragma pack > > No, that's pointless, if you use a complete rep clause, then it is > redundant to use pragma Pack since it won't have > any effect. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 11:58 ` Jeff Creem @ 2001-11-01 1:58 ` Adrian Hoe 2001-11-01 2:34 ` Jeff Creem 2001-11-01 3:53 ` Matthew Heaney 2001-11-01 3:45 ` Jeffrey Carter 2001-11-01 6:00 ` Robert Dewar 2 siblings, 2 replies; 51+ messages in thread From: Adrian Hoe @ 2001-11-01 1:58 UTC (permalink / raw) "Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>... > OK.. I know I am going to regret this since whenever I question Robert I > usually am wrong however > without using the complete context of this thread, I believe Roberts > statement is actually > a little too broad. There ARE indeed times when you want a pragma pack and a > rep spec. Not for the record case but for arrays of items that have been rep > spec'ed. > > for example, the code fragment > > type My_Type is range 0 .. 3; > for My_Type'size use 2; > > type My_Array is array (1 .. 4) of My_Type; > pragma Pack (My_Array); -- Without this the following could fail > for My_Array'size use 8; > > > The pragma pack is needed I believe because the rep spec on My_Array can > be rejected without it (At least it has been rejected by some compilers and > I forget > the exact rule but it had something to do with the final rep spec not being > allowed to > change the layout of the items within the array). > > Having said that VADS used to compile this without the pragma pack. Green > Hills did not. > I *THINK* GNAT does allow it to go through without the rep spec for several > versions now. But, why the differenct implementation by these compilers' vendors? I thought Ada is a standardized language regardless of platforms. Of course, a problem like whether to use "pragma pack" or not in the above Jeff's example "supposed" not to arise if Ada is standardized. Oh... I am getting quite confusing now, and not to mention Ada newbies! > > "Robert Dewar" <dewar@gnat.com> wrote in message > news:5ee5b646.0110301750.38ba5bfd@posting.google.com... > > john.mccabe@emrad.com.nospam (John McCabe) wrote in message > news:<3bc41989.4285341@news.demon.co.uk>... > > > Your best bet would be to use as many representation attributes as are > > > necessary. In general I would use both a representation clause and > > > pragma pack > > > > No, that's pointless, if you use a complete rep clause, then it is > > redundant to use pragma Pack since it won't have > > any effect. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-11-01 1:58 ` Adrian Hoe @ 2001-11-01 2:34 ` Jeff Creem 2001-11-01 14:58 ` Marin David Condic 2001-11-01 3:53 ` Matthew Heaney 1 sibling, 1 reply; 51+ messages in thread From: Jeff Creem @ 2001-11-01 2:34 UTC (permalink / raw) See..I knew it was too early when I wrote that. I checked and GNAT rejects it as well without the pragma pack. VADS allowed it however that was an Ada 83 implementation. In any case I stand by my basic premise that Roberts response was correct when limited to the scope of the thread (which was talking about record rep clauses) however it was too broad when taken out of context since the pragma pack should indeed by used on the array when one wants to pack the items of the array. As for the "Standardization" troll comment..There are many things in the standard that are not directly specified or are specified in terms of dependencies on the host architecture. (Word size, etc).. This is not Java. There is no standard Ada virtual machine that forces all applications to run 5-30 times slower than a native implementation (see I can troll too!). "Adrian Hoe" <byhoe@greenlime.com> wrote in message news:9ff447f2.0110311758.2be52637@posting.google.com... > "Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>... > > OK.. I know I am going to regret this since whenever I question Robert I > > usually am wrong however > > without using the complete context of this thread, I believe Roberts > > statement is actually > > a little too broad. There ARE indeed times when you want a pragma pack and a > > rep spec. Not for the record case but for arrays of items that have been rep > > spec'ed. > > > > for example, the code fragment > > > > type My_Type is range 0 .. 3; > > for My_Type'size use 2; > > > > type My_Array is array (1 .. 4) of My_Type; > > pragma Pack (My_Array); -- Without this the following could fail > > for My_Array'size use 8; > > > > > > The pragma pack is needed I believe because the rep spec on My_Array can > > be rejected without it (At least it has been rejected by some compilers and > > I forget > > the exact rule but it had something to do with the final rep spec not being > > allowed to > > change the layout of the items within the array). > > > > Having said that VADS used to compile this without the pragma pack. Green > > Hills did not. > > I *THINK* GNAT does allow it to go through without the rep spec for several > > versions now. > > > But, why the differenct implementation by these compilers' vendors? I > thought Ada is a standardized language regardless of platforms. Of > course, a problem like whether to use "pragma pack" or not in the > above Jeff's example "supposed" not to arise if Ada is standardized. > > Oh... I am getting quite confusing now, and not to mention Ada > newbies! > > > > > > > "Robert Dewar" <dewar@gnat.com> wrote in message > > news:5ee5b646.0110301750.38ba5bfd@posting.google.com... > > > john.mccabe@emrad.com.nospam (John McCabe) wrote in message > > news:<3bc41989.4285341@news.demon.co.uk>... > > > > Your best bet would be to use as many representation attributes as are > > > > necessary. In general I would use both a representation clause and > > > > pragma pack > > > > > > No, that's pointless, if you use a complete rep clause, then it is > > > redundant to use pragma Pack since it won't have > > > any effect. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-11-01 2:34 ` Jeff Creem @ 2001-11-01 14:58 ` Marin David Condic 0 siblings, 0 replies; 51+ messages in thread From: Marin David Condic @ 2001-11-01 14:58 UTC (permalink / raw) It ought to be observed that it is not possible for any language to be 100% portable across all platforms and in all cases - ESPECIALLY once you start tinkering with machine specific things like data representations. Once you take off the pannel that is marked "Caution! No User Servicable Parts Inside." all bets are off. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Jeff Creem" <jeff@thecreems.com> wrote in message news:Hw2E7.163731$vq.40606082@typhoon.ne.mediaone.net... > > As for the "Standardization" troll comment..There are many things in the > standard > that are not directly specified or are specified in terms of dependencies on > the > host architecture. (Word size, etc).. This is not Java. There is no standard > Ada > virtual machine that forces all applications to run 5-30 times slower than > a native implementation (see I can troll too!). > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-11-01 1:58 ` Adrian Hoe 2001-11-01 2:34 ` Jeff Creem @ 2001-11-01 3:53 ` Matthew Heaney 2001-11-01 18:37 ` Jeff Creem 1 sibling, 1 reply; 51+ messages in thread From: Matthew Heaney @ 2001-11-01 3:53 UTC (permalink / raw) "Adrian Hoe" <byhoe@greenlime.com> wrote in message news:9ff447f2.0110311758.2be52637@posting.google.com... > "Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>... > > for example, the code fragment > > > > type My_Type is range 0 .. 3; > > for My_Type'size use 2; > > > > type My_Array is array (1 .. 4) of My_Type; > > pragma Pack (My_Array); -- Without this the following could fail > > for My_Array'size use 8; > > > > > > The pragma pack is needed I believe because the rep spec on My_Array can > > be rejected without it Why aren't you (Jeff) specifying the array component size? for My_Array'Component_Size use 2; Won't that eliminate the need for the pragma Pack? Furthermore, isn't the size clause for My_Type redundent? The size of a type is the number of bits needed to represent all values in the type, which is 2 bits. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-11-01 3:53 ` Matthew Heaney @ 2001-11-01 18:37 ` Jeff Creem 2001-11-02 3:39 ` Robert Dewar 0 siblings, 1 reply; 51+ messages in thread From: Jeff Creem @ 2001-11-01 18:37 UTC (permalink / raw) I tend to avoid 'component size since a lot of my code needs to compile on Ada 83 and Ada 95. The pragma pack followed by the confirmatory 'size clause on the overall array should force the compiler to do what I want and if it does not (because it ignores the pragma) it will reject the final rep spec on the array. So the final 'size is not redundant. "Matthew Heaney" <mheaney@on2.com> wrote in message news:tu1hjutp4bdgf7@corp.supernews.com... > > "Adrian Hoe" <byhoe@greenlime.com> wrote in message > news:9ff447f2.0110311758.2be52637@posting.google.com... > > "Jeff Creem" <jeff@thecreems.com> wrote in message > news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>... > > > for example, the code fragment > > > > > > type My_Type is range 0 .. 3; > > > for My_Type'size use 2; > > > > > > type My_Array is array (1 .. 4) of My_Type; > > > pragma Pack (My_Array); -- Without this the following could fail > > > for My_Array'size use 8; > > > > > > > > > The pragma pack is needed I believe because the rep spec on My_Array can > > > be rejected without it > > Why aren't you (Jeff) specifying the array component size? > > for My_Array'Component_Size use 2; > > Won't that eliminate the need for the pragma Pack? > > Furthermore, isn't the size clause for My_Type redundent? The size of a > type is the number of bits needed to represent all values in the type, which > is 2 bits. > > > > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-11-01 18:37 ` Jeff Creem @ 2001-11-02 3:39 ` Robert Dewar 0 siblings, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-11-02 3:39 UTC (permalink / raw) "Jeff Creem" <jeff@thecreems.com> wrote in message news:<yDgE7.1022$kw.476665@typhoon.ne.mediaone.net>... > I tend to avoid 'component size since a lot of my code needs to compile > on Ada 83 and Ada 95. The pragma pack followed by the confirmatory > 'size clause on the overall array should force the compiler to do what I > want and > if it does not (because it ignores the pragma) it will reject the final rep > spec on the array. > > So the final 'size is not redundant. Right, my point was that the final 'Size is redundant *if* you specify the full representation, but of course if you omit the Component_Size clause you have not fulfilled this precondition. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 11:58 ` Jeff Creem 2001-11-01 1:58 ` Adrian Hoe @ 2001-11-01 3:45 ` Jeffrey Carter 2001-11-01 6:00 ` Robert Dewar 2 siblings, 0 replies; 51+ messages in thread From: Jeffrey Carter @ 2001-11-01 3:45 UTC (permalink / raw) Jeff Creem wrote: > > a little too broad. There ARE indeed times when you want a pragma pack and a > rep spec. Not for the record case but for arrays of items that have been rep > spec'ed. > > for example, the code fragment > > type My_Type is range 0 .. 3; > for My_Type'size use 2; > > type My_Array is array (1 .. 4) of My_Type; > pragma Pack (My_Array); -- Without this the following could fail > for My_Array'size use 8; Generally a compiler would use 4 bytes (or storage units) for My_Array, and without something to tell the compiler to use less storage for each component the size clause should be rejected. However, one can replace the pragma Pack with for My_Array'Component_Size use My_Type'Size; for My_Array'Size use My_Array'Length * My_Type'Size; to obtain the same effect without relying on Pack, which is allowed to be ignored. -- Jeff Carter "We call your door-opening request a silly thing." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 11:58 ` Jeff Creem 2001-11-01 1:58 ` Adrian Hoe 2001-11-01 3:45 ` Jeffrey Carter @ 2001-11-01 6:00 ` Robert Dewar 2 siblings, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-11-01 6:00 UTC (permalink / raw) "Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>... > Not for the record case but for arrays of items that have > been rep spec'ed. > > for example, the code fragment > > type My_Type is range 0 .. 3; > for My_Type'size use 2; > > type My_Array is array (1 .. 4) of My_Type; > pragma Pack (My_Array); -- Without this the following > could fail for My_Array'size use 8; Well yes, but this array has NOT been "rep spec'ed", you did not specify a component size. That's what corresponds to specifying a full record clause. So if you want to control exactly what happens, a better form of the above is: type My_Type is range 0 .. 3; for My_Type'Size use 2; type My_Array is array (1 .. 4) of My_Type; for My_Array'Component_Size use 2; for My_Array'Size use 8; the last clause is redundant, but often useful for documentation emphasis, but most certainly a pragma Pack is redundant in this case. > I *THINK* GNAT does allow it to go through without the > rep spec for several versions now. You think wrong, the size clause alone should NOT change the layout, and in GNAT it will not. Use pack if you just generally want to save space (as in the record case). Use component_Size if you want to precisely control the size of components. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe 2001-10-10 8:59 ` Alfred Hilscher @ 2001-10-10 9:24 ` Pi 2001-10-10 9:27 ` Lutz Donnerhacke ` (3 subsequent siblings) 5 siblings, 0 replies; 51+ messages in thread From: Pi @ 2001-10-10 9:24 UTC (permalink / raw) Adrian Hoe wrote : > Hello, > > I have the following declaration: > > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; 1st byte > Splitter : Character; 2nd byte > Command_Byte : Character; 3rd byte > Pad_Byte_1 : Character; 4th byte > Pad_Byte_2 : Character; 5th byte 3 bytes space to align with a memory word (32 bit) > Log_Num : Interfaces.C.Long; 8th - 12th byte > End_Byte : Character := Latin_1.ETX; 13th byte > LRC : Character; 14th byte > end record; > > It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 > bytes. 'Size will report 11 bytes when I add the following line: > > pragma pack (Rx_Header_Data); > > I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without > pragma pack. > > Why this happens? Can I use representation clause instead of pragma > pack? If both methods work, which is the best approach and why? > > I use GNAT 3.13p on Linux. > > Thank you. It's much faster to access variables that are on full word-frontiers, so GNAT adds a 3 bytes "hole" into your record. Try this definition instead : type Rx_Header_Data is record Log_Num : Interfaces.C.Long; <-------1st position Start_Byte : Character := Latin_1.STX; Splitter : Character; Command_Byte : Character; Pad_Byte_1 : Character; Pad_Byte_2 : Character; End_Byte : Character := Latin_1.ETX; LRC : Character; end record; Yes I know it's silly to simply shuffle the definitions, but it should work. Also try to compile with full optimization (-O3) and GNAT may find the shuffle himself (not sure about this) If, for some reasons, you cant shuffle the definitions, you have to use Pack. If you can, shuffle, as Pack makes your memory access slighly slower. -- 3,14159265359 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe 2001-10-10 8:59 ` Alfred Hilscher 2001-10-10 9:24 ` Pi @ 2001-10-10 9:27 ` Lutz Donnerhacke 2001-10-11 6:24 ` Adrian Hoe 2001-10-11 10:12 ` Vincent Smeets ` (2 subsequent siblings) 5 siblings, 1 reply; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-10 9:27 UTC (permalink / raw) * Adrian Hoe wrote: >I have the following declaration: > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; > Splitter : Character; > Command_Byte : Character; > Pad_Byte_1 : Character; > Pad_Byte_2 : Character; Five Bytes so far. > Log_Num : Interfaces.C.Long; > End_Byte : Character := Latin_1.ETX; > LRC : Character; > end record; > >It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 >bytes. 'Size will report 11 bytes when I add the following line: > >pragma pack (Rx_Header_Data); > >I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without >pragma pack. As expected. >Why this happens? Log_Num is aligned to use a single 64bit RAM access instead of bursting two 32bit accesses. Pragma Pack favors size over speed. >Can I use representation clause instead of pragma pack? Yes. >If both methods work, which is the best approach and why? Depends on your needs: - If you only need the small size, let the compiler choose the representation. (-gnatR shows the compilers decision) for rx_header_data_packed use record start_byte at 0 range 0 .. 7; splitter at 1 range 0 .. 7; command_byte at 2 range 0 .. 7; pad_byte_1 at 3 range 0 .. 7; log_num at 4 range 0 .. 31; -- Changed pad_byte_2 at 8 range 0 .. 7; -- Changed end_byte at 9 range 0 .. 7; lrc at 10 range 0 .. 7; end record; - If you need a special layout (i.e. for interfacing), use record representation clauses. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 9:27 ` Lutz Donnerhacke @ 2001-10-11 6:24 ` Adrian Hoe 2001-10-11 8:58 ` John McCabe 2001-10-11 9:30 ` Lutz Donnerhacke 0 siblings, 2 replies; 51+ messages in thread From: Adrian Hoe @ 2001-10-11 6:24 UTC (permalink / raw) lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9s853b.k4.lutz@taranis.iks-jena.de>... > * Adrian Hoe wrote: > >I have the following declaration: > > type Rx_Header_Data is > > record > > Start_Byte : Character := Latin_1.STX; > > Splitter : Character; > > Command_Byte : Character; > > Pad_Byte_1 : Character; > > Pad_Byte_2 : Character; > > Five Bytes so far. > > > Log_Num : Interfaces.C.Long; > > End_Byte : Character := Latin_1.ETX; > > LRC : Character; > > end record; > > > >It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 > >bytes. 'Size will report 11 bytes when I add the following line: > > > >pragma pack (Rx_Header_Data); > > > >I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without > >pragma pack. > > As expected. > > >Why this happens? > > Log_Num is aligned to use a single 64bit RAM access instead of bursting two > 32bit accesses. Pragma Pack favors size over speed. > > >Can I use representation clause instead of pragma pack? > > Yes. > > >If both methods work, which is the best approach and why? > > Depends on your needs: > - If you only need the small size, let the compiler choose the > representation. (-gnatR shows the compilers decision) > for rx_header_data_packed use record > start_byte at 0 range 0 .. 7; > splitter at 1 range 0 .. 7; > command_byte at 2 range 0 .. 7; > pad_byte_1 at 3 range 0 .. 7; > log_num at 4 range 0 .. 31; -- Changed > pad_byte_2 at 8 range 0 .. 7; -- Changed > end_byte at 9 range 0 .. 7; > lrc at 10 range 0 .. 7; > end record; > - If you need a special layout (i.e. for interfacing), > use record representation clauses. The record structure will be used to interface with COTS product which sends out data in specific byte orders. The shuffle is not viable in this case. This will be intended on 32-bit Intel. What will be the effect if I use representation clauses on 64-bit processor? Adrian ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 6:24 ` Adrian Hoe @ 2001-10-11 8:58 ` John McCabe 2001-10-11 13:20 ` Mark Johnson 2001-10-11 9:30 ` Lutz Donnerhacke 1 sibling, 1 reply; 51+ messages in thread From: John McCabe @ 2001-10-11 8:58 UTC (permalink / raw) On 10 Oct 2001 23:24:27 -0700, byhoe@greenlime.com (Adrian Hoe) wrote: >The record structure will be used to interface with COTS product which >sends out data in specific byte orders. The shuffle is not viable in >this case. I thought that may be the case, otherwise why be concerned with the structure :-) >This will be intended on 32-bit Intel. What will be the effect if I >use representation clauses on 64-bit processor? On a 64-bit Intel processor? It is likely that the layout will be the same. You may need to be concerned about endianness- although there is a 'Bit_Order attribute, in my experience a compiler is unlikely to allow you to specify a bit order that is contrary to its native ordering. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 8:58 ` John McCabe @ 2001-10-11 13:20 ` Mark Johnson 2001-10-11 16:23 ` John McCabe 2001-10-28 1:30 ` Robert Dewar 0 siblings, 2 replies; 51+ messages in thread From: Mark Johnson @ 2001-10-11 13:20 UTC (permalink / raw) John McCabe wrote: > On 10 Oct 2001 23:24:27 -0700, byhoe@greenlime.com (Adrian Hoe) wrote: > [snip] > You may need to be concerned about endianness- although there is > a 'Bit_Order attribute, in my experience a compiler is unlikely to > allow you to specify a bit order that is contrary to its native > ordering. Since Bit_Order is described in Chapter 13, all compilers should support it. However, the way GNAT (and perhaps other compilers) implement this is not the way I expected it. I expected on an Intel PC (little endian) when you say... for T'Bit_Order use System.High_Order_First; on a data type that has 'Size=32, that bit zero is the most significant bit (as it would be on an big endian sgi). That is NOT true. Bit zero is the MSB of byte zero (the least significant byte) of a four byte value. Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit) are generated after normalizing the values so that 'First_Bit is less than Storage_Unit. So something like... for C at 0 range 24..24; with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0. This is the most significant bit in a 32 bit value if you applied High_Order_First to the bit order. [sigh] It is a pain to define structures that are portable between both big and little endian machines. Almost as big a pain as the related byte swapping that is often needed. If someone wants a more detailed explanation of what we found w/ this, I suggest starting a new thread. --Mark ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 13:20 ` Mark Johnson @ 2001-10-11 16:23 ` John McCabe 2001-10-11 16:00 ` Pat Rogers 2001-10-28 1:30 ` Robert Dewar 1 sibling, 1 reply; 51+ messages in thread From: John McCabe @ 2001-10-11 16:23 UTC (permalink / raw) On Thu, 11 Oct 2001 08:20:15 -0500, Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote: >Since Bit_Order is described in Chapter 13, all compilers should support >it. There is a differenc between supporting it and doing anything useful with it, e.g. GNAT 3.12a2 or whatever it was that my last place had for Solaris was quite happy for you to say: for x'bit_order use a_order_first but blew up when you tried for x'bit_order use b_order_first (Can't remember which way round a and b were!) ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 16:23 ` John McCabe @ 2001-10-11 16:00 ` Pat Rogers 2001-10-12 8:37 ` John McCabe 0 siblings, 1 reply; 51+ messages in thread From: Pat Rogers @ 2001-10-11 16:00 UTC (permalink / raw) "John McCabe" <john.mccabe@emrad.com.nospam> wrote in message news:3bc5c72d.30703258@news.demon.co.uk... > On Thu, 11 Oct 2001 08:20:15 -0500, Mark Johnson > <Mark_H_Johnson@Raytheon.com> wrote: > > > >Since Bit_Order is described in Chapter 13, all compilers should support > >it. > > There is a differenc between supporting it and doing anything useful > with it, e.g. GNAT 3.12a2 or whatever it was that my last place had > for Solaris was quite happy for you to say: > > for x'bit_order use a_order_first > > but blew up when you tried > > for x'bit_order use b_order_first > > (Can't remember which way round a and b were!) That has changed since that (now quite old) version. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 16:00 ` Pat Rogers @ 2001-10-12 8:37 ` John McCabe 0 siblings, 0 replies; 51+ messages in thread From: John McCabe @ 2001-10-12 8:37 UTC (permalink / raw) On Thu, 11 Oct 2001 16:00:37 GMT, "Pat Rogers" <progers@classwide.com> wrote: >> There is a differenc between supporting it and doing anything useful >> with it, e.g. GNAT 3.12a2 or whatever it was that my last place had >> for Solaris was quite happy for you to say: >> >> for x'bit_order use a_order_first >> >> but blew up when you tried >> >> for x'bit_order use b_order_first >> >> (Can't remember which way round a and b were!) > > >That has changed since that (now quite old) version. That may be so, but the point was that you can't guarantee that a compiler will always behave as you think it should. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 13:20 ` Mark Johnson 2001-10-11 16:23 ` John McCabe @ 2001-10-28 1:30 ` Robert Dewar 1 sibling, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-28 1:30 UTC (permalink / raw) Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3BC59C8E.BADA210D@Raytheon.com>... > Since Bit_Order is described in Chapter 13, all compilers > should support it. That's faulty reasoning. Let's look at the RM, it says that the recommended level of support is: 7 The recommended level of support for the nondefault bit ordering is: 8 If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering. First of all, a compiler that does not implement the systems programming annex which is optional, is free to reject *any* or *all* representation clauses. Second a compiler that *does* implement the systems programming annex must treat recommended level statements in chapter 13 as requirements. Third, even if a compiler does implement the systems programming annex, it need not recognize any representation clauses other than those that correspond to these statements about recommended level of support. So what does this mean for Bit_Order a) A compiler not implementing the systems programming annex may reject all such clauses. b) A compiler that implements the systems programming annex may reject all such clauses for machines where the word size is not equal to a storage unit = all byte addressed machines = pretty much all machines around these days. So in other words, on a byte addressed machine you cannot expect the non-standard bit order to be implemented at all. Why the apparently surprising restriction? Well let's look at the definition of Bit_Order: 2 A bit ordering is a method of interpreting the meaning of the storage place attributes. High_Order_First (known in the vernacular as ``big endian'') means that the first bit of a storage element (bit 0) is the mostsignificant bit (interpreting the sequence of bits that represent a componentas an unsigned integer value). Low_Order_First (known in the vernacular as``little endian'') means the opposite: the first bit is the least significant. In other words, the attribute affects ONLY the numbering of bits WITHIN a storage unit, it does NOT affect the numbering of storage units. The thinking of the designers was that this is of very limited use on a byte addressed machine, so what's the point of requiring it to be implemented. On a word machine it is more useful. In GNAT, we decided to implement it anyway, even though this is not required, but of course we have to implement it the way the RM specifies, so it only affects the numbering of bits within a storage unit. So for example, if you have: type r is record a,b,c : integer; d : short_Integer; end record; it is meaningless to apply the non-default bit order because bit numbering within storage units is not an issue in this case GNAT will issue a warning in this case that the selection of bit order does nothing. Why a warning? Well it is our experience that lots of people (Marc included I think) expect the specification of bit order to magically fix the difference between big-endian and little-endian representations. In fact not only does it not do this at all, but there is no obvious (or even non-obvious) way to define a facility in Ada that *would* take care of this very difficult data incompatibility in an automatic manner. A few people have suggested ideas, but none of the ideas have held up. So yes, I understand that the implementation in GNAT does not meet Marc's expectations but unfortunately it is the expectations that are fundamentally wrong, the implementation is right, and any other compiler that accepts the same declarations must do the same thing (of course it would not be at all surprising if some other compiler rejected the clause on a byte addressed machine, and any use of the GNAT facility here is likely to be non-portable since it is a non-required, though allowed, extension). Robert Dewar Ada Core Technologies However, the way GNAT (and perhaps other compilers) implement this is > not the way I expected it. I expected on an Intel PC (little endian) when > you say... > for T'Bit_Order use System.High_Order_First; > on a data type that has 'Size=32, that bit zero is the most significant bit > (as it would be on an big endian sgi). That is NOT true. Bit zero is the > MSB of byte zero (the least significant byte) of a four byte value. > > Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit) > are generated after normalizing the values so that 'First_Bit is less than > Storage_Unit. So something like... > for C at 0 range 24..24; > with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0. > This is the most significant bit in a 32 bit value if you applied > High_Order_First to the bit order. > > [sigh] > > It is a pain to define structures that are portable between both big and > little endian machines. Almost as big a pain as the related byte swapping > that is often needed. If someone wants a more detailed explanation of what > we found w/ this, I suggest starting a new thread. > --Mark ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 6:24 ` Adrian Hoe 2001-10-11 8:58 ` John McCabe @ 2001-10-11 9:30 ` Lutz Donnerhacke 1 sibling, 0 replies; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-11 9:30 UTC (permalink / raw) * Adrian Hoe wrote: >lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9s853b.k4.lutz@taranis.iks-jena.de>... >> - If you need a special layout (i.e. for interfacing), >> use record representation clauses. > >The record structure will be used to interface with COTS product which >sends out data in specific byte orders. The shuffle is not viable in >this case. So use record representation clauses. >This will be intended on 32-bit Intel. What will be the effect if I >use representation clauses on 64-bit processor? With record representation clauses (including Bit_Order definitions) you can expect portable access. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe ` (2 preceding siblings ...) 2001-10-10 9:27 ` Lutz Donnerhacke @ 2001-10-11 10:12 ` Vincent Smeets 2001-10-11 10:19 ` Lutz Donnerhacke 2001-10-11 13:49 ` Ted Dennison 2001-10-26 4:00 ` Smark 5 siblings, 1 reply; 51+ messages in thread From: Vincent Smeets @ 2001-10-11 10:12 UTC (permalink / raw) Adrian Hoe wrote: > > Hello, > > I have the following declaration: > > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; > Splitter : Character; > Command_Byte : Character; > Pad_Byte_1 : Character; > Pad_Byte_2 : Character; > Log_Num : Interfaces.C.Long; > End_Byte : Character := Latin_1.ETX; > LRC : Character; > end record; > > It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 > bytes. 'Size will report 11 bytes when I add the following line: > > pragma pack (Rx_Header_Data); > > I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without > pragma pack. Just an other view and a question to CLA, If you read and write this record thrue a stream, will you then get the correct byte layout (with Log_Num at an odd byte)? -- Vincent Smeets SchlumbergerSema - Competence Center Informatik GmbH Lohberg 10 - 49716 Meppen - Germany tel: +49 5931-805-461 fax: +49 5931-805-175 mail: VSmeets@slb.com web: www.cci.de ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 10:12 ` Vincent Smeets @ 2001-10-11 10:19 ` Lutz Donnerhacke 2001-10-11 11:18 ` David C. Hoos, Sr. 0 siblings, 1 reply; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-11 10:19 UTC (permalink / raw) * Vincent Smeets wrote: >Adrian Hoe wrote: >> type Rx_Header_Data is >> record >> Start_Byte : Character := Latin_1.STX; >> Splitter : Character; >> Command_Byte : Character; >> Pad_Byte_1 : Character; >> Pad_Byte_2 : Character; >> Log_Num : Interfaces.C.Long; >> End_Byte : Character := Latin_1.ETX; >> LRC : Character; >> end record; > >Just an other view and a question to CLA, > >If you read and write this record thrue a stream, will you then get the >correct byte layout (with Log_Num at an odd byte)? I do not see a reason for expecting it. The Implementation may choose to start with a type marker and than dumps the current memory area. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 10:19 ` Lutz Donnerhacke @ 2001-10-11 11:18 ` David C. Hoos, Sr. 2001-10-11 12:06 ` Lutz Donnerhacke 0 siblings, 1 reply; 51+ messages in thread From: David C. Hoos, Sr. @ 2001-10-11 11:18 UTC (permalink / raw) To: comp.lang.ada; +Cc: Vincent.Smeets, lutz, byhoe ----- Original Message ----- From: "Lutz Donnerhacke" <lutz@iks-jena.de> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: October 11, 2001 5:19 AM Subject: Re: Size and pack > * Vincent Smeets wrote: > >Adrian Hoe wrote: > >> type Rx_Header_Data is > >> record > >> Start_Byte : Character := Latin_1.STX; > >> Splitter : Character; > >> Command_Byte : Character; > >> Pad_Byte_1 : Character; > >> Pad_Byte_2 : Character; > >> Log_Num : Interfaces.C.Long; > >> End_Byte : Character := Latin_1.ETX; > >> LRC : Character; > >> end record; > > > >Just an other view and a question to CLA, > > > >If you read and write this record thrue a stream, will you then get the > >correct byte layout (with Log_Num at an odd byte)? > > I do not see a reason for expecting it. The Implementation may choose to > start with a type marker and than dumps the current memory area. > The above answer is completely wrong. The language standard is very clear about the behavior of stream attributes. Whether this type is written with 'Outpuit or 'Write, there will be exactly eleven stream elements written to the stream. Since this is not a tagged type, there is no "type marker" to write. Furthermore, the behavior of 'Output and 'Write for this type is unaffected by how the compiler chooses to lay out the record in memory -- whether 11 bytes or 14 bytes, or some other size, or even if the compiler should choose a different order in which to lay out the components. To say "then dumps the current memory area" is misleading at best. If this _were_ a tagged type, then the behavior of 'Write would be exactly as described above, but 'Output would precede the data with the External_Tag of the type. Since an External_Tag is a string, the stream representaion of an External_Tag is first a Standard.Integer containing the length of the string, followed by the characters of the string. Furthermore, this behavior is unaffected by any representation clause or Pragma Pack. LRM 13.13.2 describes this behavior in detail. _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-11 11:18 ` David C. Hoos, Sr. @ 2001-10-11 12:06 ` Lutz Donnerhacke 0 siblings, 0 replies; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-11 12:06 UTC (permalink / raw) * David C. Hoos, Sr. wrote: >From: "Lutz Donnerhacke" <lutz@iks-jena.de> >> I do not see a reason for expecting it. The Implementation may choose to >> start with a type marker and than dumps the current memory area. > >The above answer is completely wrong. Thanx. My fault. I was irritated by endianess problems. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe ` (3 preceding siblings ...) 2001-10-11 10:12 ` Vincent Smeets @ 2001-10-11 13:49 ` Ted Dennison 2001-10-26 4:00 ` Smark 5 siblings, 0 replies; 51+ messages in thread From: Ted Dennison @ 2001-10-11 13:49 UTC (permalink / raw) In article <9ff447f2.0110100005.2503bb00@posting.google.com>, Adrian Hoe says... .. >Why this happens? Can I use representation clause instead of pragma >pack? If both methods work, which is the best approach and why? Why doesn't really matter. If your types must be a certian size and/or your record fields must be in a certian order for your program to work, then you *must* use representation and size pragmas to force that. Not specifying sizes and record field locations is in effect telling the compiler that you don't really care how big it is or where it puts things. Even if it happens to work out allright today, it might not upon your next compiler version upgrade or software port. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-10 8:05 Size and pack Adrian Hoe ` (4 preceding siblings ...) 2001-10-11 13:49 ` Ted Dennison @ 2001-10-26 4:00 ` Smark 2001-10-26 6:14 ` tmoran 2001-10-31 1:55 ` Robert Dewar 5 siblings, 2 replies; 51+ messages in thread From: Smark @ 2001-10-26 4:00 UTC (permalink / raw) "Adrian Hoe" <byhoe@greenlime.com> wrote in message news:9ff447f2.0110100005.2503bb00@posting.google.com... > Hello, > > I have the following declaration: > > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; > Splitter : Character; > Command_Byte : Character; > Pad_Byte_1 : Character; > Pad_Byte_2 : Character; > Log_Num : Interfaces.C.Long; > End_Byte : Character := Latin_1.ETX; > LRC : Character; > end record; > > It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14 > bytes. 'Size will report 11 bytes when I add the following line: > > pragma pack (Rx_Header_Data); > > I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without > pragma pack. > > Why this happens? Can I use representation clause instead of pragma > pack? If both methods work, which is the best approach and why? > > I use GNAT 3.13p on Linux. > > Thank you. As you indicated in another post, neither pragma pack nor a rep clause gives you what you want. This is because neither of these will violate the alignment rules for a given type. Unless you can use Streams_Io to read and write (and you don't have to worry about what the data looks like otherwise), you will have to do something ugly, like: type Rx_Header_Data is record Start_Byte : Character := Latin_1.STX; Splitter : Character; Command_Byte : Character; Pad_Byte_1 : Character; Pad_Byte_2 : Character; L0 : Character; L1 : Character; L2 : Character; L3 : Character; End_Byte : Character := Latin_1.ETX; LRC : Character; end record; subtype Str4 is String(1..4); function Convert is new Unchecked_Conversion (Source => Str4, Target => Interfaces.C.Long); Log_Num_Str : Str4 := Rx_Header_Data.L0 & Rx_Header_Data.L1 & Rx_Header_Data.L2 & Rx_Header_Data.L3; Log_Num : Interfaces.C.Long := Convert(Log_Num_Str); Markku ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 4:00 ` Smark @ 2001-10-26 6:14 ` tmoran 2001-10-26 17:51 ` Smark 2001-10-31 1:55 ` Robert Dewar 1 sibling, 1 reply; 51+ messages in thread From: tmoran @ 2001-10-26 6:14 UTC (permalink / raw) >As you indicated in another post, neither pragma pack nor a rep clause >gives you what you want. This is because neither of these will violate >the alignment rules for a given type. I seem to have missed the previous post, so I don't know what the problem is. The following code works just fine - isn't it what you want? type Rx_Header_Data is record Start_Byte : Character := Latin_1.STX; Splitter : Character; Command_Byte : Character; Pad_Byte_1 : Character; Pad_Byte_2 : Character; Log_Num : Interfaces.C.Long; End_Byte : Character := Latin_1.ETX; LRC : Character; end record; for Rx_Header_Data use record Start_Byte at 0 range 0 .. 7; Splitter at 1 range 0 .. 7; Command_Byte at 2 range 0 .. 7; Pad_Byte_1 at 3 range 0 .. 7; Pad_Byte_2 at 4 range 0 .. 7; Log_Num at 5 range 0 .. 31; End_Byte at 9 range 0 .. 7; LRC at 10 range 0 .. 7; end record; for Rx_Header_Data'size use 8*11; subtype str is String(1 .. 11); function to_str is new ada.unchecked_conversion(source=>Rx_Header_Data, target=>str); a : Rx_Header_Data; b : str; begin b := to_str(a); ----------- (Of course it's really ugly to use String where Storage_Element is clearly what is meant.) ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 6:14 ` tmoran @ 2001-10-26 17:51 ` Smark 2001-10-26 23:21 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: Smark @ 2001-10-26 17:51 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:8b7C7.72629$gT6.36974049@news1.rdc1.sfba.home.com... > >As you indicated in another post, neither pragma pack nor a rep clause > >gives you what you want. This is because neither of these will violate > >the alignment rules for a given type. > I seem to have missed the previous post, so I don't know what the > problem is. The following code works just fine - isn't it what you want? > type Rx_Header_Data is > record > Start_Byte : Character := Latin_1.STX; > Splitter : Character; > Command_Byte : Character; > Pad_Byte_1 : Character; > Pad_Byte_2 : Character; > Log_Num : Interfaces.C.Long; > End_Byte : Character := Latin_1.ETX; > LRC : Character; > end record; > for Rx_Header_Data use > record > Start_Byte at 0 range 0 .. 7; > Splitter at 1 range 0 .. 7; > Command_Byte at 2 range 0 .. 7; > Pad_Byte_1 at 3 range 0 .. 7; > Pad_Byte_2 at 4 range 0 .. 7; > Log_Num at 5 range 0 .. 31; > End_Byte at 9 range 0 .. 7; > LRC at 10 range 0 .. 7; > end record; > for Rx_Header_Data'size use 8*11; The problem was that this rep clause will not work, because Log_Num must be aligned to a 4-byte boundary. Some compilers will silently ignore your rep clause, I believe GNAT will tell you it can't do it. > > subtype str is String(1 .. 11); > function to_str is new ada.unchecked_conversion(source=>Rx_Header_Data, > target=>str); > a : Rx_Header_Data; > b : str; > begin > b := to_str(a); > ----------- > (Of course it's really ugly to use String where Storage_Element is clearly > what is meant.) Agreed. Markku ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 17:51 ` Smark @ 2001-10-26 23:21 ` Jeffrey Carter 2001-10-26 23:39 ` tmoran 2001-10-31 1:57 ` Robert Dewar 2 siblings, 0 replies; 51+ messages in thread From: Jeffrey Carter @ 2001-10-26 23:21 UTC (permalink / raw) Smark wrote: > > <tmoran@acm.org> wrote in message > news:8b7C7.72629$gT6.36974049@news1.rdc1.sfba.home.com... > > >As you indicated in another post, neither pragma pack nor a rep clause > > >gives you what you want. This is because neither of these will violate > > >the alignment rules for a given type. > > I seem to have missed the previous post, so I don't know what the > > problem is. The following code works just fine - isn't it what you want? > > type Rx_Header_Data is > > record > > Start_Byte : Character := Latin_1.STX; > > Splitter : Character; > > Command_Byte : Character; > > Pad_Byte_1 : Character; > > Pad_Byte_2 : Character; > > Log_Num : Interfaces.C.Long; > > End_Byte : Character := Latin_1.ETX; > > LRC : Character; > > end record; > > for Rx_Header_Data use > > record > > Start_Byte at 0 range 0 .. 7; > > Splitter at 1 range 0 .. 7; > > Command_Byte at 2 range 0 .. 7; > > Pad_Byte_1 at 3 range 0 .. 7; > > Pad_Byte_2 at 4 range 0 .. 7; > > Log_Num at 5 range 0 .. 31; > > End_Byte at 9 range 0 .. 7; > > LRC at 10 range 0 .. 7; > > end record; > > for Rx_Header_Data'size use 8*11; > > The problem was that this rep clause will not work, because Log_Num must > be aligned to a 4-byte boundary. Some compilers will silently ignore your > rep clause, I believe GNAT will tell you it can't do it. You don't seem to be paying attention. He said, "[This] code works just fine". That probably means he tested it. I have compiled and linked it with GNAT 3.13p/Win98 without any problem. On what compiler/target did your test reject this rep clause? -- Jeff Carter "I wave my private parts at your aunties." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 17:51 ` Smark 2001-10-26 23:21 ` Jeffrey Carter @ 2001-10-26 23:39 ` tmoran 2001-10-29 1:01 ` Adrian Hoe 2001-10-29 9:52 ` Lutz Donnerhacke 2001-10-31 1:57 ` Robert Dewar 2 siblings, 2 replies; 51+ messages in thread From: tmoran @ 2001-10-26 23:39 UTC (permalink / raw) > > Log_Num at 5 range 0 .. 31; > > End_Byte at 9 range 0 .. 7; > > LRC at 10 range 0 .. 7; > > end record; > > for Rx_Header_Data'size use 8*11; > > The problem was that this rep clause will not work, because Log_Num must > be aligned to a 4-byte boundary. Some compilers will silently ignore your > rep clause, I believe GNAT will tell you it can't do it. I tested it on Gnat 3.13p on Windows before posting, and Gnat was perfectly happy with it. And ARM 13.5.1(23) says that "If component clauses are given for all components, the record representation clause completely specifies the representation of the type and will be obeyed exactly by the implementation." That seems pretty unambiguous to me. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 23:39 ` tmoran @ 2001-10-29 1:01 ` Adrian Hoe 2001-10-29 2:21 ` tmoran 2001-10-29 9:52 ` Lutz Donnerhacke 1 sibling, 1 reply; 51+ messages in thread From: Adrian Hoe @ 2001-10-29 1:01 UTC (permalink / raw) tmoran@acm.org wrote in message news:<_umC7.74983$gT6.38373531@news1.rdc1.sfba.home.com>... > > > Log_Num at 5 range 0 .. 31; > > > End_Byte at 9 range 0 .. 7; > > > LRC at 10 range 0 .. 7; > > > end record; > > > for Rx_Header_Data'size use 8*11; > > > > The problem was that this rep clause will not work, because Log_Num must > > be aligned to a 4-byte boundary. Some compilers will silently ignore your > > rep clause, I believe GNAT will tell you it can't do it. > I tested it on Gnat 3.13p on Windows before posting, and Gnat was > perfectly happy with it. And ARM 13.5.1(23) says that "If component > clauses are given for all components, the record representation clause > completely specifies the representation of the type and will be obeyed > exactly by the implementation." That seems pretty unambiguous to me. I tested the code on GNAT 3.13p-7 on Linux and it works! Is having, "for Rx_Header_Data'size use 8*11;" better than pragma pack? What is the rational? I suppose the former tells the compiler exactly how many bytes/bits to be allocated for Rx_Header_Data. Adrian Hoe ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 1:01 ` Adrian Hoe @ 2001-10-29 2:21 ` tmoran 2001-10-29 10:42 ` Adrian Hoe 0 siblings, 1 reply; 51+ messages in thread From: tmoran @ 2001-10-29 2:21 UTC (permalink / raw) >Is having, "for Rx_Header_Data'size use 8*11;" better than pragma >pack? What is the rational? What I want is an 11 byte record. What a future maintainer might need to know is that it's an 11 byte record. Perhaps "pragma pack" is a way to accomplish that, and perhaps it will be obvious to a future maintainer that such a record, when packed, is 11 bytes long, but it would take mental energy, and be susceptible to error, to be sure. If I didn't care about the layout, but just wanted to minimize storage, then using "pragma pack" would be easier. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 2:21 ` tmoran @ 2001-10-29 10:42 ` Adrian Hoe 2001-10-29 23:15 ` tmoran 0 siblings, 1 reply; 51+ messages in thread From: Adrian Hoe @ 2001-10-29 10:42 UTC (permalink / raw) tmoran@acm.org wrote in message news:<633D7.83856$gT6.43463123@news1.rdc1.sfba.home.com>... > >Is having, "for Rx_Header_Data'size use 8*11;" better than pragma > >pack? What is the rational? > What I want is an 11 byte record. What a future maintainer might > need to know is that it's an 11 byte record. Perhaps "pragma pack" > is a way to accomplish that, and perhaps it will be obvious to a > future maintainer that such a record, when packed, is 11 bytes long, > but it would take mental energy, and be susceptible to error, to be sure. > If I didn't care about the layout, but just wanted to minimize storage, > then using "pragma pack" would be easier. OK. That's make the code more readable and maintainable. Is "pragma pack" equivalent to "pragma optime (space)"? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 10:42 ` Adrian Hoe @ 2001-10-29 23:15 ` tmoran 0 siblings, 0 replies; 51+ messages in thread From: tmoran @ 2001-10-29 23:15 UTC (permalink / raw) >Is "pragma pack" equivalent to "pragma optime (space)"? I doubt it. For instance, if there's just one instance of the record (not an array), the extra code to get elements from a packed version is quite likely bigger than the savings of packing. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 23:39 ` tmoran 2001-10-29 1:01 ` Adrian Hoe @ 2001-10-29 9:52 ` Lutz Donnerhacke 2001-10-29 10:29 ` Larry Kilgallen 2001-10-31 1:59 ` Robert Dewar 1 sibling, 2 replies; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-29 9:52 UTC (permalink / raw) * tmoran@acm.org wrote: >> > Log_Num at 5 range 0 .. 31; >> > End_Byte at 9 range 0 .. 7; >> > LRC at 10 range 0 .. 7; >> > end record; >> > for Rx_Header_Data'size use 8*11; >> >> The problem was that this rep clause will not work, because Log_Num must >> be aligned to a 4-byte boundary. Some compilers will silently ignore your >> rep clause, I believe GNAT will tell you it can't do it. > > I tested it on Gnat 3.13p on Windows before posting, and Gnat was >perfectly happy with it. And ARM 13.5.1(23) says that "If component >clauses are given for all components, the record representation clause >completely specifies the representation of the type and will be obeyed >exactly by the implementation." That seems pretty unambiguous to me. Compile on Alpha and get BUS ERROR. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 9:52 ` Lutz Donnerhacke @ 2001-10-29 10:29 ` Larry Kilgallen 2001-10-29 10:50 ` Lutz Donnerhacke 2001-10-31 1:59 ` Robert Dewar 1 sibling, 1 reply; 51+ messages in thread From: Larry Kilgallen @ 2001-10-29 10:29 UTC (permalink / raw) In article <slrn9tq9mi.nt.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes: > * tmoran@acm.org wrote: >>> > Log_Num at 5 range 0 .. 31; >>> > End_Byte at 9 range 0 .. 7; >>> > LRC at 10 range 0 .. 7; >>> > end record; >>> > for Rx_Header_Data'size use 8*11; >>> >>> The problem was that this rep clause will not work, because Log_Num must >>> be aligned to a 4-byte boundary. Some compilers will silently ignore your >>> rep clause, I believe GNAT will tell you it can't do it. >> >> I tested it on Gnat 3.13p on Windows before posting, and Gnat was >>perfectly happy with it. And ARM 13.5.1(23) says that "If component >>clauses are given for all components, the record representation clause >>completely specifies the representation of the type and will be obeyed >>exactly by the implementation." That seems pretty unambiguous to me. > > Compile on Alpha and get BUS ERROR. Presumably that is a runtime rather than compilation time error. You didn't say what model of Alpha, but older chips require certain instructions be aligned. VMS deals with this through alignment fault handlers that fix up such problems at a penalty of about 100 instructions. Perhaps you are on Unix or Linux (you didn't say in the body text). If so, look at your compiler instructions for something regarding which Alpha chip you are targeting. Specify an older chip and the resulting code should work on all. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 10:29 ` Larry Kilgallen @ 2001-10-29 10:50 ` Lutz Donnerhacke 2001-10-29 11:12 ` Larry Kilgallen 2001-10-31 2:00 ` Robert Dewar 0 siblings, 2 replies; 51+ messages in thread From: Lutz Donnerhacke @ 2001-10-29 10:50 UTC (permalink / raw) * Larry Kilgallen wrote: >> Compile on Alpha and get BUS ERROR. > >Presumably that is a runtime rather than compilation time error. Correct. >You didn't say what model of Alpha, but older chips require >certain instructions be aligned. VMS deals with this through >alignment fault handlers that fix up such problems at a penalty >of about 100 instructions. Perhaps you are on Unix or Linux >(you didn't say in the body text). OSF/1. Yep, and I added a pragma Atomic to provocate this effect. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 10:50 ` Lutz Donnerhacke @ 2001-10-29 11:12 ` Larry Kilgallen 2001-10-31 2:02 ` Robert Dewar 2001-10-31 2:00 ` Robert Dewar 1 sibling, 1 reply; 51+ messages in thread From: Larry Kilgallen @ 2001-10-29 11:12 UTC (permalink / raw) In article <slrn9tqd33.c7n.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes: > * Larry Kilgallen wrote: >>> Compile on Alpha and get BUS ERROR. >> >>Presumably that is a runtime rather than compilation time error. > > Correct. > >>You didn't say what model of Alpha, but older chips require >>certain instructions be aligned. VMS deals with this through >>alignment fault handlers that fix up such problems at a penalty >>of about 100 instructions. Perhaps you are on Unix or Linux >>(you didn't say in the body text). > > OSF/1. Yep, and I added a pragma Atomic to provocate this effect. RM C.6 10 "It is illegal to apply either an Atomic or Atomic_Components pragma to an object or type if the implementation cannot support the indivisible reads and updates required by the pragma" The Alpha 21064, 21064A and 21164 (at least) cannot support indivisible reads and updates of non-aligned longwords or words. That would seem to indicate that depending on the VMS fixups would not be allowed with pragma Atomic either. It certainly would not produce what I think of as being correct code for the meaning of Atomic. Some other poster can comment regarding the meaning of "illegal" vs. other pejoratives with regard to error messages generated :-) ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 11:12 ` Larry Kilgallen @ 2001-10-31 2:02 ` Robert Dewar 0 siblings, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 2:02 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<X7Zq0LolyKes@eisner.encompasserve.org>... > That would seem to indicate that depending on the VMS fixups would not > be allowed with pragma Atomic either. That would be fine if the fixup routine runs in a non-preemptible manner. There is no requirement that Atomic generate a single instruction (a conforming implementation could even take an OS lock to implement Atomic, though this is certainly not an intended implementation approach). ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 10:50 ` Lutz Donnerhacke 2001-10-29 11:12 ` Larry Kilgallen @ 2001-10-31 2:00 ` Robert Dewar 2001-10-31 2:51 ` Larry Kilgallen 1 sibling, 1 reply; 51+ messages in thread From: Robert Dewar @ 2001-10-31 2:00 UTC (permalink / raw) lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tqd33.c7n.lutz@belenus.iks-jena.de>... > OSF/1. Yep, and I added a pragma Atomic to provocate this effect. Again, this is a bug, if the compiler accepts a set of declarations, it must generate proper code. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-31 2:00 ` Robert Dewar @ 2001-10-31 2:51 ` Larry Kilgallen 0 siblings, 0 replies; 51+ messages in thread From: Larry Kilgallen @ 2001-10-31 2:51 UTC (permalink / raw) In article <5ee5b646.0110301800.55e5d2d7@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tqd33.c7n.lutz@belenus.iks-jena.de>... >> OSF/1. Yep, and I added a pragma Atomic to provocate this effect. > > Again, this is a bug, if the compiler accepts a set of > declarations, it must generate proper code. Is there no way for GNAT to generate code specific to the newer Alpha chips ? If that were done and the code were run on an older Alpha chip, I would expect a runtime error. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-29 9:52 ` Lutz Donnerhacke 2001-10-29 10:29 ` Larry Kilgallen @ 2001-10-31 1:59 ` Robert Dewar 1 sibling, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 1:59 UTC (permalink / raw) lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tq9mi.nt.lutz@taranis.iks-jena.de>... > Compile on Alpha and get BUS ERROR. If this happens it is a bug (this bug is certainly not present in the current version of GNAT). Who knows about other compilers, or earlier versions. If a compiler accepts a rep clause, it is supposed to generate working code for that rep clause. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 17:51 ` Smark 2001-10-26 23:21 ` Jeffrey Carter 2001-10-26 23:39 ` tmoran @ 2001-10-31 1:57 ` Robert Dewar 2 siblings, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 1:57 UTC (permalink / raw) "Smark" <not.provided@all.com> wrote in message news:<EohC7.32898$pb4.16108301@news2.rdc2.tx.home.com>... > The problem was that this rep clause will not work, > because Log_Num must > be aligned to a 4-byte boundary. This is simply wrong. > Some compilers will silently ignore your > rep clause, I believe GNAT will tell you it can't do it. Belief is not a good substitute for knowledge :-) This is also wrong ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Size and pack 2001-10-26 4:00 ` Smark 2001-10-26 6:14 ` tmoran @ 2001-10-31 1:55 ` Robert Dewar 1 sibling, 0 replies; 51+ messages in thread From: Robert Dewar @ 2001-10-31 1:55 UTC (permalink / raw) "Smark" <not.provided@all.com> wrote in message news:<Id5C7.31176$pb4.15277558@news2.rdc2.tx.home.com>... > As you indicated in another post, neither pragma pack nor a rep clause > gives you what you want. This is because neither of these will violate > the alignment rules for a given type. This is incorrect (I must say a thread with the above subject is almost designed to attract a fair number of incorrect posts, and the expectation is met here, this is tricky stuff). ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2001-11-02 3:39 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-10-10 8:05 Size and pack Adrian Hoe 2001-10-10 8:59 ` Alfred Hilscher 2001-10-10 9:50 ` John McCabe 2001-10-11 6:36 ` Adrian Hoe 2001-10-11 8:55 ` John McCabe 2001-10-31 1:53 ` Robert Dewar 2001-10-31 1:50 ` Robert Dewar 2001-10-31 9:17 ` John McCabe 2001-10-31 11:58 ` Jeff Creem 2001-11-01 1:58 ` Adrian Hoe 2001-11-01 2:34 ` Jeff Creem 2001-11-01 14:58 ` Marin David Condic 2001-11-01 3:53 ` Matthew Heaney 2001-11-01 18:37 ` Jeff Creem 2001-11-02 3:39 ` Robert Dewar 2001-11-01 3:45 ` Jeffrey Carter 2001-11-01 6:00 ` Robert Dewar 2001-10-10 9:24 ` Pi 2001-10-10 9:27 ` Lutz Donnerhacke 2001-10-11 6:24 ` Adrian Hoe 2001-10-11 8:58 ` John McCabe 2001-10-11 13:20 ` Mark Johnson 2001-10-11 16:23 ` John McCabe 2001-10-11 16:00 ` Pat Rogers 2001-10-12 8:37 ` John McCabe 2001-10-28 1:30 ` Robert Dewar 2001-10-11 9:30 ` Lutz Donnerhacke 2001-10-11 10:12 ` Vincent Smeets 2001-10-11 10:19 ` Lutz Donnerhacke 2001-10-11 11:18 ` David C. Hoos, Sr. 2001-10-11 12:06 ` Lutz Donnerhacke 2001-10-11 13:49 ` Ted Dennison 2001-10-26 4:00 ` Smark 2001-10-26 6:14 ` tmoran 2001-10-26 17:51 ` Smark 2001-10-26 23:21 ` Jeffrey Carter 2001-10-26 23:39 ` tmoran 2001-10-29 1:01 ` Adrian Hoe 2001-10-29 2:21 ` tmoran 2001-10-29 10:42 ` Adrian Hoe 2001-10-29 23:15 ` tmoran 2001-10-29 9:52 ` Lutz Donnerhacke 2001-10-29 10:29 ` Larry Kilgallen 2001-10-29 10:50 ` Lutz Donnerhacke 2001-10-29 11:12 ` Larry Kilgallen 2001-10-31 2:02 ` Robert Dewar 2001-10-31 2:00 ` Robert Dewar 2001-10-31 2:51 ` Larry Kilgallen 2001-10-31 1:59 ` Robert Dewar 2001-10-31 1:57 ` Robert Dewar 2001-10-31 1:55 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox