* Representation clause for enumeratives @ 2001-02-08 9:53 Sandro Binetti 2001-02-08 10:12 ` Tarjei T. Jensen ` (4 more replies) 0 siblings, 5 replies; 31+ messages in thread From: Sandro Binetti @ 2001-02-08 9:53 UTC (permalink / raw) Hi everybody, Suppose you have an enumerative type like the following: type TYP_ENUM is (A,B,C); for TYP_ENUM use( 16#00000002#, 16#00000004#, 16#80000000# -- <<<<< NOTICE THIS VALUE !!! ); My GHS AdaMulti compiler reports this error: LRM:4.9(35), The static expression which is not part of a larger static expression is outside the base range of its expected type. My Gnat compiler, on the other side, does not say anything. What's wrong with this such a 16#80000000# value? -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 9:53 Representation clause for enumeratives Sandro Binetti @ 2001-02-08 10:12 ` Tarjei T. Jensen [not found] ` <95u470$ho1$1@nnrp1.deja.com> 2001-02-08 16:22 ` Rod Chapman ` (3 subsequent siblings) 4 siblings, 1 reply; 31+ messages in thread From: Tarjei T. Jensen @ 2001-02-08 10:12 UTC (permalink / raw) Sandro Binetti wrote >type TYP_ENUM is (A,B,C); > >for TYP_ENUM use( > 16#00000002#, > 16#00000004#, > 16#80000000# -- <<<<< NOTICE THIS VALUE !!! > >); [snip] >What's wrong with this such a 16#80000000# value? Have you tried to insert a size directive. e.g type TYP_ENUM is (A,B,C); for TYP_ENUM'size use 32; for TYP_ENUM use ( 16#00000002#, 16#00000004#, 16#80000000 ); Perhaps that would work? Greetings, ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <95u470$ho1$1@nnrp1.deja.com>]
[parent not found: <95ua6q$mp4$1@nnrp1.deja.com>]
* Re: Representation clause for enumeratives [not found] ` <95ua6q$mp4$1@nnrp1.deja.com> @ 2001-02-08 15:41 ` M. Kotiaho 2001-02-08 16:27 ` Steve O'Neill 0 siblings, 1 reply; 31+ messages in thread From: M. Kotiaho @ 2001-02-08 15:41 UTC (permalink / raw) Robert Dewar wrote: > In article <95u470$ho1$1@nnrp1.deja.com>, > Sandro Binetti <sandrobinetti@my-deja.com> wrote: > > In article <95tre2$f33@news.kvaerner.com>, > > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > > > Have you tried to insert a size directive. e.g > > > > > > type TYP_ENUM is (A,B,C); > > > > > > for TYP_ENUM'size use 32; > > > > Done. But the problem is still the same ... > > Why? > > Presumably a capacity limitation in the compiler you are > using, not a terribly justifiable one, so you should bring > this to the attention of the vendor. Most likely the decision > is to use a signed 32-bit integer to represent enumerations, > which as you see in this case can be an annoying restriction. > > Sent via Deja.com > http://www.deja.com/ Indeed, GNAT on WinNT (Pentium-II) will allow the following: type TYP_ENUM is (A,B,C); for TYP_ENUM use( -16#8000000000000000#, 16#00000002#,------# 16#7FFFFFFFFFFFFFFF# -- <<<<< NOTICE THIS VALUE !!! ); Apparently, GNAT is using a signed 64-bit integer. Incidently, both compilers are sticking to the "at least" portion of the implementation advice -- they just define System.Min_Int and System.Max_Int differently: (Copied from Lutz Donnerhacke's post) >Implementation Advice > 9. The recommended level of support for enumeration_representation_clauses is: > 1. An implementation should support at least the internal codes in the > range System.Min_Int..System.Max_Int. An implementation need not > support enumeration_representation_clauses for boolean types. Markku Kotiaho ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 15:41 ` M. Kotiaho @ 2001-02-08 16:27 ` Steve O'Neill 2001-02-09 7:26 ` Sandro Binetti 2001-02-09 9:29 ` Martin Dowie 0 siblings, 2 replies; 31+ messages in thread From: Steve O'Neill @ 2001-02-08 16:27 UTC (permalink / raw) I'm making an assumption here that you are choosing these enumeration values to match to some hardware encoding. When I have found myself in similar situations in the past I have usually taken a different route. Rather than try to encode the enumeration values (which frequently leads to frustration and maintenance issues) I would instead create an array of appropriately typed objects that are indexed by the enumeration that I was trying to map. I would index into, search through, etc. that array whenever I wanted to convert to/from the external hardware to the internal meaning. It might not seem as elegant or as potentially efficient as assigning the enumeration value directly but in my experience it is a lot less painful. With the proper encapsulation and design metaphor it can actually turn out to be fairly intuitive. Steve O'Neill "M. Kotiaho" wrote: > Robert Dewar wrote: > > > In article <95u470$ho1$1@nnrp1.deja.com>, > > Sandro Binetti <sandrobinetti@my-deja.com> wrote: > > > In article <95tre2$f33@news.kvaerner.com>, > > > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > > > > Have you tried to insert a size directive. e.g > > > > > > > > type TYP_ENUM is (A,B,C); > > > > > > > > for TYP_ENUM'size use 32; > > > > > > Done. But the problem is still the same ... > > > Why? > > > > Presumably a capacity limitation in the compiler you are > > using, not a terribly justifiable one, so you should bring > > this to the attention of the vendor. Most likely the decision > > is to use a signed 32-bit integer to represent enumerations, > > which as you see in this case can be an annoying restriction. > > > > Sent via Deja.com > > http://www.deja.com/ > > Indeed, GNAT on WinNT (Pentium-II) will allow the following: > > type TYP_ENUM is (A,B,C); > > for TYP_ENUM use( > -16#8000000000000000#, > 16#00000002#,------# > 16#7FFFFFFFFFFFFFFF# -- <<<<< NOTICE THIS VALUE !!! > ); > > Apparently, GNAT is using a signed 64-bit integer. > > Incidently, both compilers are sticking to the > "at least" portion of the implementation advice -- they > just define System.Min_Int and System.Max_Int differently: > > (Copied from Lutz Donnerhacke's post) > >Implementation Advice > > 9. The recommended level of support for > enumeration_representation_clauses is: > > 1. An implementation should support at least the internal codes > in the > > range System.Min_Int..System.Max_Int. An implementation need > not > > support enumeration_representation_clauses for boolean types. > > Markku Kotiaho ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 16:27 ` Steve O'Neill @ 2001-02-09 7:26 ` Sandro Binetti 2001-02-09 9:29 ` Martin Dowie 1 sibling, 0 replies; 31+ messages in thread From: Sandro Binetti @ 2001-02-09 7:26 UTC (permalink / raw) In article <3A82C8DC.1505AC5@avidyne.com>, Steve O'Neill <soneill@avidyne.com> wrote: > I'm making an assumption here that you are choosing these enumeration > values to match to some hardware encoding. OK! That's the case! [ ... snip ... ] Thank you, Steve. -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 16:27 ` Steve O'Neill 2001-02-09 7:26 ` Sandro Binetti @ 2001-02-09 9:29 ` Martin Dowie 1 sibling, 0 replies; 31+ messages in thread From: Martin Dowie @ 2001-02-09 9:29 UTC (permalink / raw) also, if you are using the enumeration a lot for, say, array indexing _not_ having underlying representations tends to lead to much faster code. You lose a little CPU time at the interface to do the conversion, but you may find you gain many times that amount in your application. If you want to save some typing make a few generics to do the conversions. I know of several projects where precisely this sort of thing is happening (and not just limited to enumeration conversions :-). Come to think of it, I can hardly remember the last time I use a rep. clause for an enumeration... Steve O'Neill <soneill@avidyne.com> wrote in message news:3A82C8DC.1505AC5@avidyne.com... > Rather than try to encode the enumeration values (which frequently leads to > frustration and maintenance issues) I would instead create an array of > appropriately typed objects that are indexed by the enumeration that I was > trying to map. I would index into, search through, etc. that array > whenever I wanted to convert to/from the external hardware to the internal > meaning. It might not seem as elegant or as potentially efficient as > assigning the enumeration value directly but in my experience it is a lot > less painful. With the proper encapsulation and design metaphor it can > actually turn out to be fairly intuitive. [snip] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives [not found] ` <95u470$ho1$1@nnrp1.deja.com> [not found] ` <95ua6q$mp4$1@nnrp1.deja.com> @ 2001-02-08 15:55 ` Marin David Condic 1 sibling, 0 replies; 31+ messages in thread From: Marin David Condic @ 2001-02-08 15:55 UTC (permalink / raw) There is no law that says a compiler has to honor your representation clause. It can legally recognize the rep clause and just simply reject it. It is possible that your compiler has some built-in limitation that prohibits using an unsigned, 32 bit representation for an enumeration. Check with the compiler documentation or the compiler vendor. MDC Sandro Binetti wrote: > In article <95tre2$f33@news.kvaerner.com>, > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > > Have you tried to insert a size directive. e.g > > > > type TYP_ENUM is (A,B,C); > > > > for TYP_ENUM'size use 32; > > Done. But the problem is still the same ... > Why? > > -- > Ciao, Sandro > > Sent via Deja.com > http://www.deja.com/ -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 9:53 Representation clause for enumeratives Sandro Binetti 2001-02-08 10:12 ` Tarjei T. Jensen @ 2001-02-08 16:22 ` Rod Chapman 2001-02-10 6:34 ` Robert Dewar 2001-02-08 18:52 ` Greg Bek ` (2 subsequent siblings) 4 siblings, 1 reply; 31+ messages in thread From: Rod Chapman @ 2001-02-08 16:22 UTC (permalink / raw) In article <95tqbh$ag7$1@nnrp1.deja.com>, Sandro Binetti <sandrobinetti@yahoo.com> wrote: > Hi everybody, > > Suppose you have an enumerative type like the following: <snip...> Our usual coding standards for critical and real-time work advise against the use of enumerated types with rep. clauses - the code gen. and runtime impact is just too gross. Try compiling the example with "gcc -c -gnatG" and see what you get! (No particular issue with GNAT here, it's just the -gnatG option is uniquely instructive in illustrating the point). - Rod Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 16:22 ` Rod Chapman @ 2001-02-10 6:34 ` Robert Dewar 2001-02-12 11:32 ` Rod Chapman 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-10 6:34 UTC (permalink / raw) In article <95uh36$to0$1@nnrp1.deja.com>, Rod Chapman <r_c_chapman@my-deja.com> wrote: > Our usual coding standards for critical and real-time work > advise against the use of enumerated types with rep. clauses - > the code gen. and runtime impact is just too gross. I disagree with this advice, and the reason behind it. That's MUCH too broad. There is no runtime impact if you do not use the type for loops, arithmetic (succ/pred) or array subscripts. If all you use it for is just assigning and comparing and literal bit output, then this can be a valuable feature. Yes, you could use named integers, but they would allow general arithmetic which is likely meaningless. For example, if you have a type representing possible opcodes on a machine and a compiler uses them only in the context of statements like generate (shr, .....) that's perfectly reasonable, and has no deleterious runtime impact. It is almost ALWAYS wrong to advise that a particular feature of the language should NEVER be used :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 6:34 ` Robert Dewar @ 2001-02-12 11:32 ` Rod Chapman 0 siblings, 0 replies; 31+ messages in thread From: Rod Chapman @ 2001-02-12 11:32 UTC (permalink / raw) In article <962ndo$g08$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> wrote: > In article <95uh36$to0$1@nnrp1.deja.com>, > Rod Chapman <r_c_chapman@my-deja.com> wrote: > I disagree with this advice, and the reason behind it. That's > MUCH too broad. There is no runtime impact if you do not use > the type for loops, arithmetic (succ/pred) or array subscripts. Point taken - We may well add a warning to the Examiner for those usages. - Rod Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-08 9:53 Representation clause for enumeratives Sandro Binetti 2001-02-08 10:12 ` Tarjei T. Jensen 2001-02-08 16:22 ` Rod Chapman @ 2001-02-08 18:52 ` Greg Bek [not found] ` <Ndyg6.1048$y03.96769@news.flash.net> [not found] ` <3A829EB8.A098925E@baesystems.com> 4 siblings, 0 replies; 31+ messages in thread From: Greg Bek @ 2001-02-08 18:52 UTC (permalink / raw) Sandro, What I think is happening is that AdaMulti is using a 32 bit signed type to represent enumerated values. The 16#8000_0000# value is outside this range. The supplied example compiles with Apex. But if for instance you changed it to 16#8_0000_0000# (thinking you had more than 32 bits) you would get the error: 10:28:19 >>> Line 8: for Typ_Enum use (16#00000002#, 16#00000004#, 16#8_0000_0000#); 10:28:19 *** The internal codes exceed the values representable with the largest target integer type This is because Apex uses a 32 bit unsigned type to store enumerated values. Basically you have hit a compiler limit. I'm not sure if you can use a negative number for the enumerated values with your compiler, if you can then reordering your enumerated type declaration to: type Typ_Enum is (C, A, B); for Typ_Enum use (-16#80000000#,16#00000002#, 16#00000004# ) --^^^^ note the minus sign Greg ------------------------------------------- Greg Bek mailto:gab@rational.com Product Manager Rational Software, Cupertino CA 95014 Ph: +1 408 863 4394 Fax: + 1 408 863 4180 ------------------------------------------- Sandro Binetti wrote in message <95tqbh$ag7$1@nnrp1.deja.com>... > Hi everybody, > >Suppose you have an enumerative type like the following: > >type TYP_ENUM is (A,B,C); > >for TYP_ENUM use( > 16#00000002#, > 16#00000004#, > 16#80000000# -- <<<<< NOTICE THIS VALUE !!! > >); > >My GHS AdaMulti compiler reports this error: > > LRM:4.9(35), The static expression which is not part of a larger >static expression is outside the base range of its expected type. > >My Gnat compiler, on the other side, does not say anything. > >What's wrong with this such a 16#80000000# value? >-- >Ciao, Sandro > > >Sent via Deja.com >http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <Ndyg6.1048$y03.96769@news.flash.net>]
* Re: Representation clause for enumeratives [not found] ` <Ndyg6.1048$y03.96769@news.flash.net> @ 2001-02-09 5:02 ` Ken Garlington 2001-02-10 6:29 ` Robert Dewar 2001-02-10 6:19 ` Robert Dewar 1 sibling, 1 reply; 31+ messages in thread From: Ken Garlington @ 2001-02-09 5:02 UTC (permalink / raw) As an aside, here's some fun you can have with the following package in GNAT 3.12p: : package Big_Enum is : : type Object is (A, B, C); : : for Object use( : 16#0000_0002#, : 16#0000_0004#, : 16#8000_0000# : ); : : for Object'Size use 32; : : end Big_Enum; -- This works: for Object use( 16#0000_0000#, 16#7FFF_FFFF#, 16#8000_0000# ); -- But change it to the following, and you get "value not in range of type 'Standard.Integer'" -- (I only changed the first value to -1; it's not in Standard.Integer? :) for Object use( -1, 16#7FFF_FFFF#, 16#8000_0000# ); -- This works fine.... for Object use( 1, 2, 16#FFFF_FFFF# ); -- But the following draws the Standard.Integer message... for Object use( -16#FFFF_FFFF#, -2, -1 ); Tsk - these limited enumeration representation ranges... :) I wouldn't mind this behavior in a numeric type... type Hardware_Numeric is range (-16#8000# .. 16#7FFF#) or ( 16#0000# .. 16#FFFF#); A : Hardware_Numeric := -1; -- all further literals must be in range of first clause... X : Hardware_Numeric := 16#8000#; -- all further literals must be in range of second clause... Get that into Ada 0Y for me, will ya? :) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-09 5:02 ` Ken Garlington @ 2001-02-10 6:29 ` Robert Dewar 2001-02-10 16:37 ` Ken Garlington 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-10 6:29 UTC (permalink / raw) In article <LRKg6.1443$y03.158823@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > As an aside, here's some fun you can have with the following package in GNAT > 3.12p: > > : package Big_Enum is > : > : type Object is (A, B, C); > : > : for Object use( > : 16#0000_0002#, > : 16#0000_0004#, > : 16#8000_0000# > : ); That's fine, GNAT will use a 32-bit unsigned representation > -- But change it to the following, and you get "value not in >range of type > 'Standard.Integer'" > -- (I only changed the first value to -1; it's not in Standard.Integer? :) > > for Object use( > -1, > 16#7FFF_FFFF#, > 16#8000_0000# > ); No, it's the 2**31 value at the end (16#8000_0000#) that is not in the range of Standard.Integer. GNAT will use a 32 bit unsigned representation if it can, but if you use a negative value, you force the use of a signed representation. Note that biasing is not an option here, since the values must denote actual representations. > -- This works fine.... > > for Object use( > 1, > 2, > 16#FFFF_FFFF# > ); Because a 32-bit unsigned representation can be used > -- But the following draws the Standard.Integer message... > > for Object use( > -16#FFFF_FFFF#, > -2, > -1 > ); Because now a 32-bit unsigned representation cannot be used, so a 32-bit signed representation must be used and the first value is out of range. > Tsk - these limited enumeration representation ranges... :) Reread the above comments and I think things will be clear. GNAT does its best to satisfy the semantic requirements, while obeying the size restriction you have placed. It will choose either a signed or unsigned representation, extending the number of cases that can be covered, but it cannot fit more bits into 32 bits than fit :-) > I wouldn't mind this behavior in a numeric type... > > type Hardware_Numeric is range (-16#8000# .. 16#7FFF#) or ( 16#0000# .. > 16#FFFF#); > > A : Hardware_Numeric := -1; -- all further literals must be in range of > first clause... > X : Hardware_Numeric := 16#8000#; -- all further literals must be in range > of second clause... > > Get that into Ada 0Y for me, will ya? :) Hmmm! I think we will place more emphasis on the smiley here than the suggestion :-) :-) But you are confusing issues here, most certainly the idea of a single type that somehow flips between signed and unsigned is of course ludicrous. But here we have separate types, and the RM quite specifically does NOT specify limitations on the ranges of values that can be accepted, so the compiler is free to choose any appropriate underlying representation type. Yes, it is definitely a non-required, but very useful, behavior that GNAT will use either signed or unsigned representations here (after all, the ability to use a signed representation gives the original questioner what they wanted). P.S. The one undesirable behavior in GNAT that I see, and will fix is that the error flag is not clearly placed on the particular literal that is causing trouble! > > Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 6:29 ` Robert Dewar @ 2001-02-10 16:37 ` Ken Garlington 2001-02-10 17:29 ` Robert Dewar 2001-02-10 17:31 ` Robert Dewar 0 siblings, 2 replies; 31+ messages in thread From: Ken Garlington @ 2001-02-10 16:37 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:962n4v$fmg$1@nnrp1.deja.com... : In article <LRKg6.1443$y03.158823@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > As an aside, here's some fun you can have with the following : package in GNAT : > 3.12p: : : > -- But change it to the following, and you get "value not in : >range of type : > 'Standard.Integer'" : > -- (I only changed the first value to -1; it's not in : Standard.Integer? :) : > : > for Object use( : > -1, : > 16#7FFF_FFFF#, : > 16#8000_0000# : > ); : : No, it's the 2**31 value at the end (16#8000_0000#) that : is not in the range of Standard.Integer. GNAT will use a : 32 bit unsigned representation if it can, but if you use : a negative value, you force the use of a signed representation. Hence the smiley face :) in the prior post :) By the way, this description of the shifting of the allowable range (selecting different unbiased representations) would be very useful in the GNAT user guide. I couldn't find it. : P.S. The one undesirable behavior in GNAT that I see, and will : fix is that the error flag is not clearly placed on the : particular literal that is causing trouble! Which was also my point. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 16:37 ` Ken Garlington @ 2001-02-10 17:29 ` Robert Dewar 2001-02-11 1:09 ` Ken Garlington 2001-02-10 17:31 ` Robert Dewar 1 sibling, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-10 17:29 UTC (permalink / raw) In article <27eh6.3787$y03.254014@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > By the way, this description > of the shifting of the allowable range (selecting different > unbiased representations) would be very useful in the GNAT > user guide. I couldn't find it. Information on representation matters is really part of the language, and in particular is required to be documented by RM M(43). All such information is in the GNAT reference manual, not in the users guide (which is about how to use the compiler, rather than how to write programs). The divisision is not always perfectly clear, but in this case, there is a chapter called "Representation Clauses and Pragmas", which a section called "Enumeration Clauses", that contains this information as well as other important information. In particular, one very important item which is (very unfortunately) left implementation defined is what happens if you have an array whose index type is an enumeration type with holes. There are two implementations: 1. Use the representation to index, fast, but can waste space (a lot of space if you have a rep clause like the one that started this thread). 2. Use the pos value to index, slow, but compact GNAT chooses the second, mostly because Verdix chose the second, and we generally choose to be Verdix Ada 83 compatible in such matters (in this case, this is also the choice made by DEC Ada 83 and other Ada 83 compilers). Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 17:29 ` Robert Dewar @ 2001-02-11 1:09 ` Ken Garlington 2001-02-11 5:27 ` Robert Dewar 0 siblings, 1 reply; 31+ messages in thread From: Ken Garlington @ 2001-02-11 1:09 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:963tos$atu$1@nnrp1.deja.com... : In article <27eh6.3787$y03.254014@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > By the way, this description : > of the shifting of the allowable range (selecting different : > unbiased representations) would be very useful in the GNAT : > user guide. I couldn't find it. : : Information on representation matters is really part of the : language, and in particular is required to be documented by : RM M(43). All such information is in the GNAT reference manual, : not in the users guide (which is about how to use the compiler, : rather than how to write programs). The divisision is not : always perfectly clear, but in this case, there is a chapter : called "Representation Clauses and Pragmas", which a section : called "Enumeration Clauses", that contains this information : as well as other important information. Perhaps this is in the 3.13p version of the reference manual? My version 3.12p dated 6 September 1999 does not have the specific information I suggested. I searched for the word "representation", and found the following with at least minimal bearing on the subject: [Under "Implementation Defined Pragmas"] No_Enumeration_Maps - similar to Discard_Names in C.5, but this is a restriction instead. For enumeration types with representation clauses the following attributes are not allowed.... [Under "Implementation Defined Attributes"] Enum_Rep - for every enumeration subtype S, S'Enum_Rep denotes a function.... [Under "Implementation Advice"] 3.5.5(8): Enumeration Values - For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond.... Followed. 13.4(9-10): Enumeration Representation Clauses - The recommended level of support for enumeration representation clauses is: An implementation need not support enumeration representation clauses for boolean types, but should at minimum support the internal codes in the range System.Min_Int.System.Max_Int [sic]. Followed. [Under "Interfacing to Other Languages" -> "Interfacing to C"] Ada enumeration types map to C enumeration types directly if pragma Convention C is specified, which causes them to have int length. Without pragma Convention C, Ada enumeration types map to 8, 16, or 32 bits (i.e. C types signed char, short, int respectively) depending on the number of values passed. This is the only case in which pragma Convention C affects the representation of an Ada type. [Under "Compatibility Guide" -> "Representation Clauses"] There is no mention of enumeration representation clauses in this section. : In particular, one very important item which is (very : unfortunately) left implementation defined is what happens : if you have an array whose index type is an enumeration type : with holes. There are two implementations: : : 1. Use the representation to index, fast, but can waste space : (a lot of space if you have a rep clause like the one that : started this thread). : : 2. Use the pos value to index, slow, but compact : : GNAT chooses the second, mostly because Verdix chose the : second, and we generally choose to be Verdix Ada 83 compatible : in such matters (in this case, this is also the choice made by : DEC Ada 83 and other Ada 83 compilers). This must also have been introduced after the 3.12p version... : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 1:09 ` Ken Garlington @ 2001-02-11 5:27 ` Robert Dewar 2001-02-11 12:53 ` Laurent Guerby 2001-02-11 14:50 ` Ken Garlington 0 siblings, 2 replies; 31+ messages in thread From: Robert Dewar @ 2001-02-11 5:27 UTC (permalink / raw) In article <9Dlh6.4497$y03.296626@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > (lots of comments on an obsolete version of GNAT > documentation snipped) > Perhaps this is in the 3.13p version of the reference manual? > My version 3.12p dated 6 September 1999 does not have the > specific information I > suggested. Ahem -- we are now well into the 21st century, and indeed the 18 month old version you refer to is VERY out of date. 3.13 has been out for a year, and 3.14 will appear shortly. I suggest updating :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 5:27 ` Robert Dewar @ 2001-02-11 12:53 ` Laurent Guerby 2001-02-12 0:24 ` Robert Dewar 2001-02-11 14:50 ` Ken Garlington 1 sibling, 1 reply; 31+ messages in thread From: Laurent Guerby @ 2001-02-11 12:53 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > Ahem -- we are now well into the 21st century, and indeed the > 18 month old version you refer to is VERY out of date. 3.13 > has been out for a year, and 3.14 will appear shortly. I > suggest updating :-) May be more users would update and reread documentation if each new manual had a "new and updated" section. (I already made this remark has a customer BTW, so this is not only "free user" wishlist ;-) You can't expect users to reread a few hundred (boring even if well-written) pages they've already mostly read every six monthes and do the mental diff (if it's even possible). The release notes for the technical part is very good, why not do the same for the documentation? I really hope the GNAT 3.14 documentation will have such a section, otherwise I probably won't read it, and this will nullify GNAT people work on it (at least for me). -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 12:53 ` Laurent Guerby @ 2001-02-12 0:24 ` Robert Dewar 2001-02-12 20:10 ` Laurent Guerby 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-12 0:24 UTC (permalink / raw) In article <86pugpbct5.fsf@acm.org>, Laurent Guerby <guerby@acm.org> wrote: > May be more users would update and reread documentation if > each new manual had a "new and updated" section. (I already > made this remark has a customer BTW, so this is not only > "free user" wishlist ;-) The features file is intended to exactly satisfy this need. What we see most customers doing is to read through the features file (it's pretty long, but that's because there are a lot of new features :-) Each feature has a few line description, and if you are interested in finding more, then you can look in the manual for details. > You can't expect users to reread a few hundred (boring even > if well-written) pages they've already mostly read every six > monthes and do the mental diff (if it's even possible). Exactly, that's why we provide the features file. > The release notes for the technical part is very good, why > not do the same for the documentation? > > I really hope the GNAT 3.14 documentation will have such a > section, otherwise I probably won't read it, and this will > nullify GNAT people work on it (at least for me). You should read through the features file. That ends up being a guide for new documentation features as well as new technical features in the compiler. For example, here is one of several entries in the 3.14 features file relating to documentation: NF-314-7718-001 Linker_Options extensions now documented The documentation (GNAT Reference Manual) has been enhanced to contain full documentation of the GNAT implementation of the Linker_Options pragma. GNAT allows multiple arguments, and also allows the use of ASCII.NUL to separate arguments in a single string. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-12 0:24 ` Robert Dewar @ 2001-02-12 20:10 ` Laurent Guerby 0 siblings, 0 replies; 31+ messages in thread From: Laurent Guerby @ 2001-02-12 20:10 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > Laurent Guerby <guerby@acm.org> wrote: > > The release notes for the technical part is very good, why > > not do the same for the documentation? > > > > I really hope the GNAT 3.14 documentation will have such a > > section, otherwise I probably won't read it, and this will > > nullify GNAT people work on it (at least for me). > > You should read through the features file. That ends up being > a guide for new documentation features as well as new technical > features in the compiler. For example, here is one of several > entries in the 3.14 features file relating to documentation: I do read and appreciate the feature file (as said in the first paragraph). However, I don't think all the changes to the documentation are mentionned (editorial, reorganisation and corrections as well as new features doc, well all that's worth rereading in the new documentation version), if the 3.14 feature is more complete on this point that's great! -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 5:27 ` Robert Dewar 2001-02-11 12:53 ` Laurent Guerby @ 2001-02-11 14:50 ` Ken Garlington 1 sibling, 0 replies; 31+ messages in thread From: Ken Garlington @ 2001-02-11 14:50 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:9657rb$biv$1@nnrp1.deja.com... : In article <9Dlh6.4497$y03.296626@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : : > (lots of comments on an obsolete version of GNAT : > documentation snipped) : : > Perhaps this is in the 3.13p version of the reference manual? : > My version 3.12p dated 6 September 1999 does not have the : > specific information I : > suggested. : : Ahem -- we are now well into the 21st century, and indeed the : 18 month old version you refer to is VERY out of date. 3.13 : has been out for a year, and 3.14 will appear shortly. I : suggest updating :-) I know, I'm terrible about that. For example, I am *still* using Windows 98! (How long has the public release of 3.13 been available? The download site has file dates of 8/2/2000...) : : : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 16:37 ` Ken Garlington 2001-02-10 17:29 ` Robert Dewar @ 2001-02-10 17:31 ` Robert Dewar 2001-02-11 1:09 ` Ken Garlington 1 sibling, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-10 17:31 UTC (permalink / raw) In article <27eh6.3787$y03.254014@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > : P.S. The one undesirable behavior in GNAT that I see, and > : will fix is that the error flag is not clearly placed on > : the particular literal that is causing trouble! > > Which was also my point. OK, well it would help to be a little less obscure when making such points in future :-) In particular, the flag is placed on the representation clause itself, not on the wrong literal, so it is not wrongly placed, just not as specifically placed as you might like. What is quite helpful is to quote -gnatl output in such cases in comp.lang.ada listings, because then it is very clear what the message is applying to, if you only quote the brief errors we don't really know what line numbers are being referenced, because we don't have the full program. In fact I would not have noticed this at all if I had not bothered to make a full example and compile it myself! Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 17:31 ` Robert Dewar @ 2001-02-11 1:09 ` Ken Garlington 2001-02-11 5:28 ` Robert Dewar 0 siblings, 1 reply; 31+ messages in thread From: Ken Garlington @ 2001-02-11 1:09 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:963tu2$b0f$1@nnrp1.deja.com... : In article <27eh6.3787$y03.254014@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > : P.S. The one undesirable behavior in GNAT that I see, and : > : will fix is that the error flag is not clearly placed on : > : the particular literal that is causing trouble! : > : > Which was also my point. : : OK, well it would help to be a little less obscure when making : such points in future :-) In particular, the flag is placed on : the representation clause itself, not on the wrong literal, so : it is not wrongly placed, just not as specifically placed as : you might like. : : What is quite helpful is to quote -gnatl output in such cases : in comp.lang.ada listings, because then it is very clear what : the message is applying to, if you only quote the brief errors : we don't really know what line numbers are being referenced, : because we don't have the full program. I'd like that, but I use the AdaGIDE that comes with 3.12p, and it doesn't allow the messages to be cut and pasted. : In fact I would not have noticed this at all if I had not : bothered to make a full example and compile it myself! : : : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 1:09 ` Ken Garlington @ 2001-02-11 5:28 ` Robert Dewar 2001-02-11 14:50 ` Ken Garlington 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-11 5:28 UTC (permalink / raw) In article <aDlh6.4498$y03.296626@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > I'd like that, but I use the AdaGIDE that comes with 3.12p, > and it doesn't allow the messages to be cut and pasted. Again, I suggest an update, also it is really not that hard to enter the necessary commands (surely someone coming from a VMS background can manage to do things in command mode :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 5:28 ` Robert Dewar @ 2001-02-11 14:50 ` Ken Garlington 2001-02-12 0:30 ` Robert Dewar 0 siblings, 1 reply; 31+ messages in thread From: Ken Garlington @ 2001-02-11 14:50 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:9657ua$bjh$1@nnrp1.deja.com... : In article <aDlh6.4498$y03.296626@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > I'd like that, but I use the AdaGIDE that comes with 3.12p, : > and it doesn't allow the messages to be cut and pasted. : : Again, I suggest an update, also it is really not that hard : to enter the necessary commands (surely someone coming from : a VMS background can manage to do things in command mode :-) Manage, yes -- but there's a difference from it being *possible* and being *easy* to do (particularly when you're scrambling to finish exploring the idea before going to work, and you haven't used command mode in a while). Surely someone coming from an Ada background understands this distinction :) In any case, I downloaded 3.13p (and AdaGIDE, which still doesn't allow copies from the message screen). The 3.13p reference manual is much clearer on the subject, although the phrase "The only restriction on enumeration clauses is that the range of values must be representable" is still open to interpretation. For example, I'd argue that -16#FFFF_FFFF# .. -1 is both "representable" in 32 bits and in the range System.Min_Int .. System.Max_Int. Words about treating a set with no negative values as unsigned values, and as unbiased signed values otherwise would have been clearer to me. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-11 14:50 ` Ken Garlington @ 2001-02-12 0:30 ` Robert Dewar 2001-02-12 2:34 ` Ken Garlington 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 2001-02-12 0:30 UTC (permalink / raw) In article <OExh6.5397$y03.334735@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > For example, I'd argue that -16#FFFF_FFFF# .. -1 is both > "representable" in 32 bits and in the range System.Min_Int .. > System.Max_Int. > Words about treating a set with no negative values as > unsigned values, and as unbiased signed values otherwise > would have been clearer to me. Don't hesitate to make documentation suggestions, many improvements to the documentation come from suggestions sent to report@gnat.com. In this particular case, the RM of course does not allow biasing of representations when an enumeration representation clause is present, since this is one of the few (really the only) case where the RM has something to say about representation, and indeed the ACVC tests (I wrote the relevant ones :-) test this by doing unchecked conversion. But it never hurts to emphasize things in the documentation, so I agree it would be helpful to point out that biased representations cannot be used for enumeration types! Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-12 0:30 ` Robert Dewar @ 2001-02-12 2:34 ` Ken Garlington 0 siblings, 0 replies; 31+ messages in thread From: Ken Garlington @ 2001-02-12 2:34 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:967ar9$sq7$1@nnrp1.deja.com... : In article <OExh6.5397$y03.334735@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > For example, I'd argue that -16#FFFF_FFFF# .. -1 is both : > "representable" in 32 bits and in the range System.Min_Int .. : > System.Max_Int. : : > Words about treating a set with no negative values as : > unsigned values, and as unbiased signed values otherwise : > would have been clearer to me. : : Don't hesitate to make documentation suggestions, many : improvements to the documentation come from suggestions : sent to report@gnat.com. : : In this particular case, the RM of course does not allow : biasing of representations when an enumeration representation : clause is present, since this is one of the few (really the : only) case where the RM has something to say about : representation, and indeed the ACVC tests (I wrote the relevant : ones :-) test this by doing unchecked conversion. Would "biased" be the correct term for a representation of -16#FFFF_FFFF# .. -1, where you use two's complement convention to store all negative numbers (and ignore overflow)? I'm also curious about how the ACVC tests use unchecked conversion in a portable manner in this case. In particular, what are you converting _to_? : But it never hurts to emphasize things in the documentation, : so I agree it would be helpful to point out that biased : representations cannot be used for enumeration types! : : : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives [not found] ` <Ndyg6.1048$y03.96769@news.flash.net> 2001-02-09 5:02 ` Ken Garlington @ 2001-02-10 6:19 ` Robert Dewar 2001-02-10 11:42 ` David C. Hoos, Sr. 2001-02-10 16:37 ` Ken Garlington 1 sibling, 2 replies; 31+ messages in thread From: Robert Dewar @ 2001-02-10 6:19 UTC (permalink / raw) In article <Ndyg6.1048$y03.96769@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > I don't know if either behavior is considered "wrong" by the standard. I'm > not comfortable with the GNAT behavior, since it treats 16#8000_0000# as a > legal 32-bit integer value, although it is not in the range Standard.Integer > on the same machine. Who says that the range of enumeration values is restricted to Standard.Integer, in fact no one says it, and the RH in the RM encourages you to go up to maxint which for GNAT is 2**63-1. Why you should be uncomfortable because GNAT does NOT implement a limitation which (a) would not be helpful (b) would violate implementation advice is puzzling indeed! > This just encourages the confusion between hex numbers > and bit-patterns. I do see the utility of doing it this way, > however. I don't understand the confusion. GNAT chooses a large enough signed or unsigned integer type to cover the range of values provided. Note that 16#8000_0000# is the number 2**32, it is a POSITIVE number, nothing at all to do with the largest negative number. I think the confusion is coming from the use of base 16, and suddenly that is translating into bit patterns in your mind??? Any time you write 16#8000_0000# in your program, you could equally well write 2147483648. The meaning is 100% identical. If the first looks like a bit pattern to you, and the second looks like an integer, then that's your confusion, not Ada's :-) Sent via Deja.com http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 6:19 ` Robert Dewar @ 2001-02-10 11:42 ` David C. Hoos, Sr. 2001-02-10 16:37 ` Ken Garlington 1 sibling, 0 replies; 31+ messages in thread From: David C. Hoos, Sr. @ 2001-02-10 11:42 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:962mh2$f9v$1@nnrp1.deja.com... > In article <Ndyg6.1048$y03.96769@news.flash.net>, > "Ken Garlington" <Ken.Garlington@computer.org> wrote: > > I don't know if either behavior is considered "wrong" by the > standard. I'm > > not comfortable with the GNAT behavior, since it treats > 16#8000_0000# as a <snip> > Note that 16#8000_0000# is the number 2**32, it is a POSITIVE I believe Robert meant 2**31 here. > number, nothing at all to do with the largest negative number. > I think the confusion is coming from the use of base 16, and > suddenly that is translating into bit patterns in your mind??? > > Any time you write 16#8000_0000# in your program, you could > equally well write 2147483648. The meaning is 100% identical. > If the first looks like a bit pattern to you, and the second > looks like an integer, then that's your confusion, not Ada's > :-) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Representation clause for enumeratives 2001-02-10 6:19 ` Robert Dewar 2001-02-10 11:42 ` David C. Hoos, Sr. @ 2001-02-10 16:37 ` Ken Garlington 1 sibling, 0 replies; 31+ messages in thread From: Ken Garlington @ 2001-02-10 16:37 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:962mh2$f9v$1@nnrp1.deja.com... : In article <Ndyg6.1048$y03.96769@news.flash.net>, : "Ken Garlington" <Ken.Garlington@computer.org> wrote: : > I don't know if either behavior is considered "wrong" by the : standard. I'm : > not comfortable with the GNAT behavior, since it treats : 16#8000_0000# as a : > legal 32-bit integer value, although it is not in the range : Standard.Integer : > on the same machine. : : Who says that the range of enumeration values is restricted : to Standard.Integer, in fact no one says it... Well, actually GNAT says it under certain circumstances... see subsequent posts! This is the part I'm not confortable with... that the allowable range for a enumeration type which is explicitly constrained to 32 bits shifts depending upon how the enumeration values are written. Again, I see its utility in practice, but I can also see how it might confuse new Ada users who try to do the same thing in different contexts (see end). , and the RH in : the RM encourages you to go up to maxint which for GNAT : is 2**63-1. Why you should be uncomfortable because GNAT : does NOT implement a limitation which : : (a) would not be helpful : (b) would violate implementation advice : : is puzzling indeed! : : > This just encourages the confusion between hex numbers : > and bit-patterns. I do see the utility of doing it this way, : > however. : : I don't understand the confusion. GNAT chooses a large enough : signed or unsigned integer type to cover the range of values : provided. : : Note that 16#8000_0000# is the number 2**32, it is a POSITIVE : number, nothing at all to do with the largest negative number. : I think the confusion is coming from the use of base 16, and : suddenly that is translating into bit patterns in your mind??? : : Any time you write 16#8000_0000# in your program, you could : equally well write 2147483648. The meaning is 100% identical. : If the first looks like a bit pattern to you, and the second : looks like an integer, then that's your confusion, not Ada's : :-) Actually, the confusion is from the original poster (we really have to work on your social skills, Robert :). The confusion is that 16#8000_0000# does, indeed, look very much like a bit pattern as represented in certain other popular languages. Further adding to the confusion is that this enumeration value, when read as an Integer, is in fact not 2147483648 but -2147483648. Particularly for engineers with a hardware/assembly background (who also tend to be the ones who want to write this kind of code), the distinction between an Unsigned_Integer, an Integer, and an integer on a two's-complement machine is often difficult to grasp. Trust me -- I get to hear about this confusion all of the time. In fact, on one recent project, I had to write and distribute a three-page paper on this sort of distinction due to the number of questions in this area (e.g. "Why won't this stupid compiler do bit strings right?"). : : : Sent via Deja.com : http://www.deja.com/ ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <3A829EB8.A098925E@baesystems.com>]
[parent not found: <95uae3$n5j$1@nnrp1.deja.com>]
* Re: Representation clause for enumeratives [not found] ` <95uae3$n5j$1@nnrp1.deja.com> @ 2001-02-12 9:12 ` Stuart Palin 0 siblings, 0 replies; 31+ messages in thread From: Stuart Palin @ 2001-02-12 9:12 UTC (permalink / raw) Robert Dewar wrote: > > In article <3A829EB8.A098925E@baesystems.com>, > Stuart Palin <stuart.palin@baesystems.com> wrote: <snip some rubbish code> > You could try it, but it would of course not compile :-) <snip compiler response> > > It is always a good idea to try compiling examples before > you post them. I supposedly know Ada reasonably well, but I > still find it easy to have a mind-slip now and then, and try > to follow this discipline myself :-) I plead guilty to ignoring Robert's oft given advice, and apologize to the court :-) I would write out the proper answer 100 times - but I don't think anyone would like that; however, for the record I provide what I should have written (checked with XD-Ada [83]). type TYP_ENUM is (C,A,B); -- NOTICE: 'C' has the lowest value representation and -- so must come first. for TYP_ENUM use( -16#80000000#, -- NOTICE: the "-" 16#00000002#, 16#00000004#); (other caveats and advice given elsewhere in this thread apply) -- Stuart Palin ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2001-02-12 20:10 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-02-08 9:53 Representation clause for enumeratives Sandro Binetti 2001-02-08 10:12 ` Tarjei T. Jensen [not found] ` <95u470$ho1$1@nnrp1.deja.com> [not found] ` <95ua6q$mp4$1@nnrp1.deja.com> 2001-02-08 15:41 ` M. Kotiaho 2001-02-08 16:27 ` Steve O'Neill 2001-02-09 7:26 ` Sandro Binetti 2001-02-09 9:29 ` Martin Dowie 2001-02-08 15:55 ` Marin David Condic 2001-02-08 16:22 ` Rod Chapman 2001-02-10 6:34 ` Robert Dewar 2001-02-12 11:32 ` Rod Chapman 2001-02-08 18:52 ` Greg Bek [not found] ` <Ndyg6.1048$y03.96769@news.flash.net> 2001-02-09 5:02 ` Ken Garlington 2001-02-10 6:29 ` Robert Dewar 2001-02-10 16:37 ` Ken Garlington 2001-02-10 17:29 ` Robert Dewar 2001-02-11 1:09 ` Ken Garlington 2001-02-11 5:27 ` Robert Dewar 2001-02-11 12:53 ` Laurent Guerby 2001-02-12 0:24 ` Robert Dewar 2001-02-12 20:10 ` Laurent Guerby 2001-02-11 14:50 ` Ken Garlington 2001-02-10 17:31 ` Robert Dewar 2001-02-11 1:09 ` Ken Garlington 2001-02-11 5:28 ` Robert Dewar 2001-02-11 14:50 ` Ken Garlington 2001-02-12 0:30 ` Robert Dewar 2001-02-12 2:34 ` Ken Garlington 2001-02-10 6:19 ` Robert Dewar 2001-02-10 11:42 ` David C. Hoos, Sr. 2001-02-10 16:37 ` Ken Garlington [not found] ` <3A829EB8.A098925E@baesystems.com> [not found] ` <95uae3$n5j$1@nnrp1.deja.com> 2001-02-12 9:12 ` Stuart Palin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox