* Enumeration representation clause surprise. @ 2008-06-11 11:38 Markus Schoepflin 2008-06-11 12:30 ` christoph.grein 2008-06-12 19:05 ` richtmyer 0 siblings, 2 replies; 42+ messages in thread From: Markus Schoepflin @ 2008-06-11 11:38 UTC (permalink / raw) Hello, please consider the following code snippet: type ENUM_T is (ONE, TWO); for ENUM_T use (ONE => 1, TWO => 2); type RECORD_T is record A1 : ENUM_T; A2 : ENUM_T; end record; for RECORD_T use record A1 at 0 range 0 .. 0; -- (*) A2 at 1 range 0 .. 7; end record; for RECORD_T'Size use 2 * 8; FOO : RECORD_T; I was _very_ surprised to discover that when executing FOO.A1 := TWO; FOO.A2 := TWO; the binary content of FOO looks like this: 00000010 00000001 IOW, for A1 ONE is coded as 0 and TWO as 1, and for A2 ONE is coded as 1 and TWO as 2. I checked this with GNAT 3.4.5 and some old DEC Ada compiler, therefore I think this behaviour is compiler independent. Anybody knows why the compiler is allowed to silently ignore my representation clause for the enumeration? I would have expected to get an error at the indicated line, telling me that A1 is too small. BTW, this was found in a real word application, where code like this was used to model a given external interface, and later the enumeration was extended by a few values, but the record representation clause was never updated. Is there a way I can protect myself from this very nasty trap? Best regards, Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 11:38 Enumeration representation clause surprise Markus Schoepflin @ 2008-06-11 12:30 ` christoph.grein 2008-06-11 12:56 ` Markus Schoepflin 2008-06-12 19:05 ` richtmyer 1 sibling, 1 reply; 42+ messages in thread From: christoph.grein @ 2008-06-11 12:30 UTC (permalink / raw) What you request for A1 seems impossible: Store value 2 = 2#01# in one bit. An illustrating example: type My_Int is range 10_000 .. 10_001; type My_Record is record I: My_Int; end record; for My_Record use record I at 0 range 0 .. 0; end record; This is allowed. My_Record holds only two values, so one bit is enough. The compiler uses a so-called biased representation with 10_000 as bias, which need not be stored. Hope this helps. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 12:30 ` christoph.grein @ 2008-06-11 12:56 ` Markus Schoepflin 2008-06-11 13:08 ` christoph.grein 2008-06-11 13:28 ` Samuel Tardieu 0 siblings, 2 replies; 42+ messages in thread From: Markus Schoepflin @ 2008-06-11 12:56 UTC (permalink / raw) christoph.grein@eurocopter.com wrote: > What you request for A1 seems impossible: Store value 2 = 2#01# in one > bit. This is exactly my point. I would have expected a compile time error for this impossible request. Representation clauses are (amongst other) meant to specify specific binary layouts for interfacing with the external world. Or am I mistaken here? > An illustrating example: > > type My_Int is range 10_000 .. 10_001; > > type My_Record is record > I: My_Int; > end record; > > for My_Record use record > I at 0 range 0 .. 0; > end record; > > This is allowed. My_Record holds only two values, so one bit is > enough. The compiler uses a so-called biased representation with > 10_000 as bias, which need not be stored. Yes, I am aware that this feature exists, I am just unhappy that it is also allowed for enumerations. Is there another Ada mechanism for specifying external interfaces like this one? One that does not have the same subtle maintenance trap? > Hope this helps. Thanks, Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 12:56 ` Markus Schoepflin @ 2008-06-11 13:08 ` christoph.grein 2008-06-11 13:28 ` Samuel Tardieu 1 sibling, 0 replies; 42+ messages in thread From: christoph.grein @ 2008-06-11 13:08 UTC (permalink / raw) Hm, I gather you have detected a nice way to shoot yourself in the foot :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 12:56 ` Markus Schoepflin 2008-06-11 13:08 ` christoph.grein @ 2008-06-11 13:28 ` Samuel Tardieu 2008-06-11 13:48 ` Markus Schoepflin 2008-06-11 14:58 ` Adam Beneschan 1 sibling, 2 replies; 42+ messages in thread From: Samuel Tardieu @ 2008-06-11 13:28 UTC (permalink / raw) Markus> This is exactly my point. I would have expected a compile time error Markus> for this impossible request. Markus> Representation clauses are (amongst other) meant to specify specific Markus> binary layouts for interfacing with the external world. Or am I Markus> mistaken here? I can't find anything in RM chapter 13 which either forbids or allows such a behaviour. I will submit a patch for GNAT which gives a new warning for this case: 11. A1 at 0 range 0 .. 0; -- (*) | >>> warning: component representation will be biased Sam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 13:28 ` Samuel Tardieu @ 2008-06-11 13:48 ` Markus Schoepflin 2008-06-11 13:56 ` Samuel Tardieu 2008-06-11 14:58 ` Adam Beneschan 1 sibling, 1 reply; 42+ messages in thread From: Markus Schoepflin @ 2008-06-11 13:48 UTC (permalink / raw) Samuel Tardieu wrote: > Markus> This is exactly my point. I would have expected a compile time error > Markus> for this impossible request. > > Markus> Representation clauses are (amongst other) meant to specify specific > Markus> binary layouts for interfacing with the external world. Or am I > Markus> mistaken here? > > I can't find anything in RM chapter 13 which either forbids or allows > such a behaviour. I will submit a patch for GNAT which gives a new > warning for this case: > > 11. A1 at 0 range 0 .. 0; -- (*) > | > >>> warning: component representation will be biased > > Sam That would be extremely helpful! Thanks, Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 13:48 ` Markus Schoepflin @ 2008-06-11 13:56 ` Samuel Tardieu 0 siblings, 0 replies; 42+ messages in thread From: Samuel Tardieu @ 2008-06-11 13:56 UTC (permalink / raw) Sam> I will submit a patch for GNAT which gives a new warning for this Sam> case Markus> That would be extremely helpful! Done, at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00680.html ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 13:28 ` Samuel Tardieu 2008-06-11 13:48 ` Markus Schoepflin @ 2008-06-11 14:58 ` Adam Beneschan 2008-06-11 15:23 ` Markus Schoepflin 2008-06-11 15:56 ` Samuel Tardieu 1 sibling, 2 replies; 42+ messages in thread From: Adam Beneschan @ 2008-06-11 14:58 UTC (permalink / raw) On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote: > Markus> This is exactly my point. I would have expected a compile time error > Markus> for this impossible request. > > Markus> Representation clauses are (amongst other) meant to specify specific > Markus> binary layouts for interfacing with the external world. Or am I > Markus> mistaken here? > > I can't find anything in RM chapter 13 which either forbids or allows > such a behaviour. I will submit a patch for GNAT which gives a new > warning for this case: > > 11. A1 at 0 range 0 .. 0; -- (*) > | > >>> warning: component representation will be biased This seems odd to me. Having GNAT select a biased component in Christoph's example makes some sense, since a compiler can choose any representation it likes. But in Markus' case, he specifically asked for a certain representation for the enumeration types---should GNAT take it upon itself to change that, and display a warning that doesn't make it clear that it's disrespecting his request to have the enumeration represented a certain way? I dunno... maybe this would be acceptable to some, and apparently Markus thinks it's OK, but ... it's just not what I would expect ... I guess it's a subjective thing. -- Adam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 14:58 ` Adam Beneschan @ 2008-06-11 15:23 ` Markus Schoepflin 2008-06-12 2:37 ` Randy Brukardt 2008-06-12 2:37 ` Randy Brukardt 2008-06-11 15:56 ` Samuel Tardieu 1 sibling, 2 replies; 42+ messages in thread From: Markus Schoepflin @ 2008-06-11 15:23 UTC (permalink / raw) Adam Beneschan wrote: > On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote: >> Markus> This is exactly my point. I would have expected a compile time error >> Markus> for this impossible request. >> >> Markus> Representation clauses are (amongst other) meant to specify specific >> Markus> binary layouts for interfacing with the external world. Or am I >> Markus> mistaken here? >> >> I can't find anything in RM chapter 13 which either forbids or allows >> such a behaviour. I will submit a patch for GNAT which gives a new >> warning for this case: >> >> 11. A1 at 0 range 0 .. 0; -- (*) >> | >> >>> warning: component representation will be biased > > This seems odd to me. Having GNAT select a biased component in > Christoph's example makes some sense, since a compiler can choose any > representation it likes. But in Markus' case, he specifically asked > for a certain representation for the enumeration types---should GNAT > take it upon itself to change that, and display a warning that doesn't > make it clear that it's disrespecting his request to have the > enumeration represented a certain way? Do you suggest to reword the warning? Or give an error instead? > > I dunno... maybe this would be acceptable to some, and apparently > Markus thinks it's OK, but ... it's just not what I would expect ... > I guess it's a subjective thing. Actually I'm OK with anything that gives me a way to detect this, be it warning, error, or whatever. Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 15:23 ` Markus Schoepflin @ 2008-06-12 2:37 ` Randy Brukardt 2008-06-12 2:37 ` Randy Brukardt 1 sibling, 0 replies; 42+ messages in thread From: Randy Brukardt @ 2008-06-12 2:37 UTC (permalink / raw) "Markus Schoepflin" <nospam@no.spam> wrote in message news:g2oqld$qli$1@nntp.ilk.net... > Adam Beneschan wrote: >> On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote: >>> Markus> This is exactly my point. I would have expected a compile time >>> error >>> Markus> for this impossible request. >>> >>> Markus> Representation clauses are (amongst other) meant to specify >>> specific >>> Markus> binary layouts for interfacing with the external world. Or am I >>> Markus> mistaken here? >>> >>> I can't find anything in RM chapter 13 which either forbids or allows >>> such a behaviour. I will submit a patch for GNAT which gives a new >>> warning for this case: >>> >>> 11. A1 at 0 range 0 .. 0; -- (*) >>> | >>> >>> warning: component representation will be biased >> >> This seems odd to me. Having GNAT select a biased component in >> Christoph's example makes some sense, since a compiler can choose any >> representation it likes. But in Markus' case, he specifically asked >> for a certain representation for the enumeration types---should GNAT >> take it upon itself to change that, and display a warning that doesn't >> make it clear that it's disrespecting his request to have the >> enumeration represented a certain way? > > Do you suggest to reword the warning? Or give an error instead? I agree with Adam (whose message I mysteriously didn't receive). Even if the letter of the RM allows this sort of behavior, it seems wrong from an expectation basis: an explicitly given representation clause is being ignored where there is a conflict between two of them. That's never a good thing. So I think this should be an error - a compiler shouldn't be changing explicitly given representation items. (I realize that this may not be a generally held opinion.) For the record, Janus/Ada gives: In File D:\Testing\Win\console\rep.ada at line 11 -------------- 10: for RECORD_T use record 11: A1 at 0 range 0 .. 0; -- (*) ----------------------------------^ *ERROR* More bits are needed to store all values of the type (6.4.17) [RM 13.5.1(19)] Continue <Sp> or Abort <^C>? for this example. But that's not all that interesting, because Janus/Ada doesn't support biased representations. Randy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 15:23 ` Markus Schoepflin 2008-06-12 2:37 ` Randy Brukardt @ 2008-06-12 2:37 ` Randy Brukardt 1 sibling, 0 replies; 42+ messages in thread From: Randy Brukardt @ 2008-06-12 2:37 UTC (permalink / raw) "Markus Schoepflin" <nospam@no.spam> wrote in message news:g2oqld$qli$1@nntp.ilk.net... > Adam Beneschan wrote: >> On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote: >>> Markus> This is exactly my point. I would have expected a compile time >>> error >>> Markus> for this impossible request. >>> >>> Markus> Representation clauses are (amongst other) meant to specify >>> specific >>> Markus> binary layouts for interfacing with the external world. Or am I >>> Markus> mistaken here? >>> >>> I can't find anything in RM chapter 13 which either forbids or allows >>> such a behaviour. I will submit a patch for GNAT which gives a new >>> warning for this case: >>> >>> 11. A1 at 0 range 0 .. 0; -- (*) >>> | >>> >>> warning: component representation will be biased >> >> This seems odd to me. Having GNAT select a biased component in >> Christoph's example makes some sense, since a compiler can choose any >> representation it likes. But in Markus' case, he specifically asked >> for a certain representation for the enumeration types---should GNAT >> take it upon itself to change that, and display a warning that doesn't >> make it clear that it's disrespecting his request to have the >> enumeration represented a certain way? > > Do you suggest to reword the warning? Or give an error instead? I agree with Adam (whose message I mysteriously didn't receive). Even if the letter of the RM allows this sort of behavior, it seems wrong from an expectation basis: an explicitly given representation clause is being ignored where there is a conflict between two of them. That's never a good thing. So I think this should be an error - a compiler shouldn't be changing explicitly given representation items. (I realize that this may not be a generally held opinion.) For the record, Janus/Ada gives: In File D:\Testing\Win\console\rep.ada at line 11 -------------- 10: for RECORD_T use record 11: A1 at 0 range 0 .. 0; -- (*) ----------------------------------^ *ERROR* More bits are needed to store all values of the type (6.4.17) [RM 13.5.1(19)] Continue <Sp> or Abort <^C>? for this example. But that's not all that interesting, because Janus/Ada doesn't support biased representations. Randy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 14:58 ` Adam Beneschan 2008-06-11 15:23 ` Markus Schoepflin @ 2008-06-11 15:56 ` Samuel Tardieu 2008-06-11 19:10 ` Adam Beneschan 1 sibling, 1 reply; 42+ messages in thread From: Samuel Tardieu @ 2008-06-11 15:56 UTC (permalink / raw) Adam> This seems odd to me. Having GNAT select a biased component in Adam> Christoph's example makes some sense, since a compiler can choose any Adam> representation it likes. But in Markus' case, he specifically asked Adam> for a certain representation for the enumeration types---should GNAT Adam> take it upon itself to change that, and display a warning that doesn't Adam> make it clear that it's disrespecting his request to have the Adam> enumeration represented a certain way? Adam> Adam> I dunno... maybe this would be acceptable to some, and apparently Adam> Markus thinks it's OK, but ... it's just not what I would expect ... Adam> I guess it's a subjective thing. I would prefer an error indeed, but I can't seem to find a clause in chapter 13 which says that in records with representation clauses the representation given for objects when created independently the enumeration representation clause must be honored. Anyway, the patch I submitted will probably be evaluated by AdaCore language lawyers. If an error must be signalled, then the warning will be transformed into one. Sam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 15:56 ` Samuel Tardieu @ 2008-06-11 19:10 ` Adam Beneschan 2008-06-11 19:59 ` Niklas Holsti 0 siblings, 1 reply; 42+ messages in thread From: Adam Beneschan @ 2008-06-11 19:10 UTC (permalink / raw) On Jun 11, 8:56 am, Samuel Tardieu <s...@rfc1149.net> wrote: > Adam> This seems odd to me. Having GNAT select a biased component in > Adam> Christoph's example makes some sense, since a compiler can choose any > Adam> representation it likes. But in Markus' case, he specifically asked > Adam> for a certain representation for the enumeration types---should GNAT > Adam> take it upon itself to change that, and display a warning that doesn't > Adam> make it clear that it's disrespecting his request to have the > Adam> enumeration represented a certain way? > Adam> > Adam> I dunno... maybe this would be acceptable to some, and apparently > Adam> Markus thinks it's OK, but ... it's just not what I would expect ... > Adam> I guess it's a subjective thing. > > I would prefer an error indeed, Then there's no reason it couldn't generate one... implementations are allowed to reject any representation clauses (including component clauses) that they don't support, and there's nothing in the Implementation Advice of 13.5.1 that would "require" (or advise) an implementation to support this. (In fact, there's nothing that would "require" an implementation to implement biased values as in Christopher's example.) > but I can't seem to find a clause in > chapter 13 which says that in records with representation clauses the > representation given for objects when created independently the > enumeration representation clause must be honored. Technically, that may be correct, although technically it may be that the RM doesn't require the specified representation to be honored for *any* objects, stand-alone or component. At least I couldn't find anything specific, unless this is "generally implied" by the whole chapter or by 13.1. It may be that it's legal for an implementation to accept an enumeration representation clause and then never apply it. But components are objects, and I don't see anything in 13.4 that would apply unequally to component objects vis-a-vis stand-alone objects. Anyway, since it's clearly legal for an implementation to reject Markus' code, I think it should. Although it may be *possible* that an implementation *could* find a way to obey the record rep clause by using a different representation for the enumeration component (if this is indeed legal), there's a 0% chance that any such usage would be what the programmer intended, and a 100% chance that a usage like this would indicate an error on the programmer's part. -- Adam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 19:10 ` Adam Beneschan @ 2008-06-11 19:59 ` Niklas Holsti 2008-06-12 1:16 ` tmoran 2008-06-12 8:45 ` Markus Schoepflin 0 siblings, 2 replies; 42+ messages in thread From: Niklas Holsti @ 2008-06-11 19:59 UTC (permalink / raw) Adam Beneschan wrote: > ... technically it may be that > the RM doesn't require the specified representation to be honored for > *any* objects, stand-alone or component. At least I couldn't find > anything specific, unless this is "generally implied" by the whole > chapter or by 13.1. It may be that it's legal for an implementation > to accept an enumeration representation clause and then never apply > it. There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion may be used to query the internal codes used for an enumeration type". I don't know if "Notes" are normative parts of the standard. It would be interesting to know what Unchecked_Conversion gives for the 1-bit record component in Markus' problematic record. If it gives 0 and 1, as encoded, and not 1 and 2, as required in the enumeration representation clause, it would seem to violate this "Note". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 19:59 ` Niklas Holsti @ 2008-06-12 1:16 ` tmoran 2008-06-12 8:27 ` christoph.grein 2008-06-12 8:45 ` Markus Schoepflin 1 sibling, 1 reply; 42+ messages in thread From: tmoran @ 2008-06-12 1:16 UTC (permalink / raw) >There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion >may be used to query the internal codes used for an enumeration type". That, along with 13.4(7) "An enumeration representation clause specifies the coding aspect of representation. The coding consists of the internal code for each enumeration literal, ..." sure sounds to me like an Unchecked_Conversion should return the internal code set by the enumeration representation clause, ie, the number 1 or number 2 in this case. The fact the variable in question is in a record shouldn't make that false. RM 13.1(1) says about representation items (a superset of representation clauses) that "They can be provided to ... or to interface with features that are outside the domain of the language (for example, peripheral hardware)." In this case that clearly would not work. And if the compiler is going to ignore something the programmer asked for, it ought to at least generate a warning. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 1:16 ` tmoran @ 2008-06-12 8:27 ` christoph.grein 0 siblings, 0 replies; 42+ messages in thread From: christoph.grein @ 2008-06-12 8:27 UTC (permalink / raw) On 12 Jun., 03:16, tmo...@acm.org wrote: > >There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion > >may be used to query the internal codes used for an enumeration type". > Tom wrote: > That, along with 13.4(7) "An enumeration representation clause > specifies the coding aspect of representation. The coding consists of the > internal code for each enumeration literal, ..." sure sounds to me like > an Unchecked_Conversion should return the internal code set by the > enumeration representation clause, ie, the number 1 or number 2 in this > case. The fact the variable in question is in a record shouldn't make > that false. This is a non sequitur. type My_Record is record I: My_Int; end record; for My_Record use record I at 0 range 0 .. 0; end record; Also in this case an Unchecked_Conversion gives different results for I declared as a record component or by itself. But I support the other reasons why the actual aspect clause should possibly be rejected. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 19:59 ` Niklas Holsti 2008-06-12 1:16 ` tmoran @ 2008-06-12 8:45 ` Markus Schoepflin 2008-06-12 16:43 ` Mike Silva 1 sibling, 1 reply; 42+ messages in thread From: Markus Schoepflin @ 2008-06-12 8:45 UTC (permalink / raw) Niklas Holsti wrote: > Adam Beneschan wrote: > >> ... technically it may be that >> the RM doesn't require the specified representation to be honored for >> *any* objects, stand-alone or component. At least I couldn't find >> anything specific, unless this is "generally implied" by the whole >> chapter or by 13.1. It may be that it's legal for an implementation >> to accept an enumeration representation clause and then never apply >> it. > > There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion may be > used to query the internal codes used for an enumeration type". I don't > know if "Notes" are normative parts of the standard. It would be > interesting to know what Unchecked_Conversion gives for the 1-bit record > component in Markus' problematic record. If it gives 0 and 1, as > encoded, and not 1 and 2, as required in the enumeration representation > clause, it would seem to violate this "Note". Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are correctly debiasing when explicitly asked for the internal representation. Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 8:45 ` Markus Schoepflin @ 2008-06-12 16:43 ` Mike Silva 2008-06-12 18:41 ` Markus Schöpflin 0 siblings, 1 reply; 42+ messages in thread From: Mike Silva @ 2008-06-12 16:43 UTC (permalink / raw) On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote: > > Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are > correctly debiasing when explicitly asked for the internal representation. > > Markus Now I'm really confused. In your OP you showed some "incorrect" binary values - how did you get those values? By inspecting memory? Now you talk about explicitly asking for the internal representation. What does that mean exactly? Are you saying now that there's no problem after all? Mike ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 16:43 ` Mike Silva @ 2008-06-12 18:41 ` Markus Schöpflin 2008-06-12 20:10 ` Mike Silva 0 siblings, 1 reply; 42+ messages in thread From: Markus Schöpflin @ 2008-06-12 18:41 UTC (permalink / raw) Mike Silva schrieb: > On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote: >> Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are >> correctly debiasing when explicitly asked for the internal representation. >> >> Markus > > Now I'm really confused. In your OP you showed some "incorrect" > binary values - how did you get those values? By inspecting memory? Yes. > Now you talk about explicitly asking for the internal representation. > What does that mean exactly? Using unchecked conversion to ask for the value of the variables. > Are you saying now that there's no problem after all? Not at all. The memory layout of the variables is not what I expect it to be, because the compiler silently biased those values. The compiler is perfectly aware of this, as it makes up for the biasing when explicitly querying the value, but this doesn't help at all because I'm interested in the exact bitwise representation. Admittedly, there is an inconsistency in what I'm asking the compiler to do, but that's the whole point: I do not want this inconsistency to be silently 'fixed' by the compiler, I want to get noted about my error to get a chance and fix it myself. > Mike Regards, Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 18:41 ` Markus Schöpflin @ 2008-06-12 20:10 ` Mike Silva 2008-06-12 20:52 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Mike Silva @ 2008-06-12 20:10 UTC (permalink / raw) On Jun 12, 2:41 pm, Markus Schöpflin <nos...@nospam.org> wrote: > Mike Silva schrieb: > > > On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote: > >> Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are > >> correctly debiasing when explicitly asked for the internal representation. > > >> Markus > > > Now I'm really confused. In your OP you showed some "incorrect" > > binary values - how did you get those values? By inspecting memory? > > Yes. > > > Now you talk about explicitly asking for the internal representation. > > What does that mean exactly? > > Using unchecked conversion to ask for the value of the variables. > > > Are you saying now that there's no problem after all? > > Not at all. The memory layout of the variables is not what I expect it > to be, because the compiler silently biased those values. The compiler > is perfectly aware of this, as it makes up for the biasing when > explicitly querying the value, but this doesn't help at all because I'm > interested in the exact bitwise representation. > > Admittedly, there is an inconsistency in what I'm asking the compiler to > do, but that's the whole point: I do not want this inconsistency to be > silently 'fixed' by the compiler, I want to get noted about my error to > get a chance and fix it myself. I wonder then if this is an error at all. IANALL, but if the program makes available your specified values when queried with the proper mechanism (in this case, unchecked conversion), then I don't see what difference it makes how it stores the representations in raw memory. I'd welcome other comments on the validity or non-validity of this view. Mike ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 20:10 ` Mike Silva @ 2008-06-12 20:52 ` Simon Wright 2008-06-12 23:36 ` Mike Silva 2008-06-13 7:21 ` Keith Thompson 2008-06-13 9:14 ` Jean-Pierre Rosen 2 siblings, 1 reply; 42+ messages in thread From: Simon Wright @ 2008-06-12 20:52 UTC (permalink / raw) Mike Silva <snarflemike@yahoo.com> writes: > I wonder then if this is an error at all. IANALL, but if the > program makes available your specified values when queried with the > proper mechanism (in this case, unchecked conversion), then I don't > see what difference it makes how it stores the representations in > raw memory. The only reason I have ever written representation clauses is to ensure that the contents of raw memory are what some external hardware (or software, eg at the other end of a network connection) requires them to be. So I really really don't want the compiler to do anything other than what I asked for; and if it can't, to reject the representation loudly and fatally! Given OP's declarations type Enum_T is (One, Two); for Enum_T use (One => 1, Two => 2); type Record_T is record A1 : Enum_T; A2 : Enum_T; end record; for Record_T use record A1 at 0 range 0 .. 0; A2 at 1 range 0 .. 7; end record; for Record_T'Size use 2 * 8; Foo : Record_T; there's a huge difference between an unchecked conversion of the value Foo.A1 to <whatever>, which might quite reasonably have the bias removed, and UC of the value Foo as a whole, which wouldn't. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 20:52 ` Simon Wright @ 2008-06-12 23:36 ` Mike Silva 2008-06-13 5:49 ` Simon Wright 0 siblings, 1 reply; 42+ messages in thread From: Mike Silva @ 2008-06-12 23:36 UTC (permalink / raw) On Jun 12, 4:52 pm, Simon Wright <simon.j.wri...@mac.com> wrote: > Mike Silva <snarflem...@yahoo.com> writes: > > I wonder then if this is an error at all. IANALL, but if the > > program makes available your specified values when queried with the > > proper mechanism (in this case, unchecked conversion), then I don't > > see what difference it makes how it stores the representations in > > raw memory. > > The only reason I have ever written representation clauses is to > ensure that the contents of raw memory are what some external hardware > (or software, eg at the other end of a network connection) requires > them to be. OK, I understand that - so how would you pass this raw memory to the external hardware or software? And in this case, how did the use of biased representations ever get into compilers at all? Is there any possible use of biased representations that does not fail the requirement you have established? I'm not arguing, just trying to understand the issue. Mike ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 23:36 ` Mike Silva @ 2008-06-13 5:49 ` Simon Wright 0 siblings, 0 replies; 42+ messages in thread From: Simon Wright @ 2008-06-13 5:49 UTC (permalink / raw) Mike Silva <snarflemike@yahoo.com> writes: > On Jun 12, 4:52�pm, Simon Wright <simon.j.wri...@mac.com> wrote: >> The only reason I have ever written representation clauses is to >> ensure that the contents of raw memory are what some external >> hardware (or software, eg at the other end of a network connection) >> requires them to be. > > OK, I understand that - so how would you pass this raw memory to the > external hardware or software? Obtain the address to which the hardware registers are mapped (talking VME here) & convert to a pointer to a structure which describes how the hardware expects to see memory, then write through that pointer. Or, for example, function To_Stream_Element here: http://coldframe.cvs.sourceforge.net/coldframe/adasntp/SNTP.impl/sntp_support.adb?revision=1.4&view=markup where I'm packing an unrepresented Status into a single byte for transmission. Nowadays I might do this using shift-and-mask to avoid messing with endianness (this code has to work with Ada 95, even if the new 05 features would help). > And in this case, how did the use of > biased representations ever get into compilers at all? Is there any > possible use of biased representations that does not fail the > requirement you have established? If I don't care how the compiler wedges the data into the record so long as it's as small as possible (pragma Pack) then a biased rep would be quite reasonable. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 20:10 ` Mike Silva 2008-06-12 20:52 ` Simon Wright @ 2008-06-13 7:21 ` Keith Thompson 2008-06-13 13:31 ` Mike Silva 2008-06-13 9:14 ` Jean-Pierre Rosen 2 siblings, 1 reply; 42+ messages in thread From: Keith Thompson @ 2008-06-13 7:21 UTC (permalink / raw) Mike Silva <snarflemike@yahoo.com> writes: > On Jun 12, 2:41�pm, Markus Sch�pflin <nos...@nospam.org> wrote: >> Mike Silva schrieb: [...] >> > Are you saying now that there's no problem after all? >> >> Not at all. The memory layout of the variables is not what I expect it >> to be, because the compiler silently biased those values. The compiler >> is perfectly aware of this, as it makes up for the biasing when >> explicitly querying the value, but this doesn't help at all because I'm >> interested in the exact bitwise representation. >> >> Admittedly, there is an inconsistency in what I'm asking the compiler to >> do, but that's the whole point: I do not want this inconsistency to be >> silently 'fixed' by the compiler, I want to get noted about my error to >> get a chance and fix it myself. > > I wonder then if this is an error at all. IANALL, but if the program > makes available your specified values when queried with the proper > mechanism (in this case, unchecked conversion), then I don't see what > difference it makes how it stores the representations in raw memory. > > I'd welcome other comments on the validity or non-validity of this > view. If it doesn't make any difference how the representations are stored in raw memory, then you wouldn't use a representation clause; you'd let the compiler make any decisions about representation, subject to the constraint that the code has to produce the right answers. But if you *do* provide a representation clause, then the representation clearly *does* matter. And if the compiler can't satisfy the requested representation (e.g., because two representation clauses contradict each other), then the compiler should reject the compilation unit. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 7:21 ` Keith Thompson @ 2008-06-13 13:31 ` Mike Silva 2008-06-13 14:45 ` Markus Schoepflin 2008-06-13 17:52 ` Keith Thompson 0 siblings, 2 replies; 42+ messages in thread From: Mike Silva @ 2008-06-13 13:31 UTC (permalink / raw) On Jun 13, 3:21 am, Keith Thompson <ks...@mib.org> wrote: > Mike Silva <snarflem...@yahoo.com> writes: > > On Jun 12, 2:41 pm, Markus Schöpflin <nos...@nospam.org> wrote: > >> Mike Silva schrieb: > [...] > >> > Are you saying now that there's no problem after all? > > >> Not at all. The memory layout of the variables is not what I expect it > >> to be, because the compiler silently biased those values. The compiler > >> is perfectly aware of this, as it makes up for the biasing when > >> explicitly querying the value, but this doesn't help at all because I'm > >> interested in the exact bitwise representation. > > >> Admittedly, there is an inconsistency in what I'm asking the compiler to > >> do, but that's the whole point: I do not want this inconsistency to be > >> silently 'fixed' by the compiler, I want to get noted about my error to > >> get a chance and fix it myself. > > > I wonder then if this is an error at all. IANALL, but if the program > > makes available your specified values when queried with the proper > > mechanism (in this case, unchecked conversion), then I don't see what > > difference it makes how it stores the representations in raw memory. > > > I'd welcome other comments on the validity or non-validity of this > > view. > > If it doesn't make any difference how the representations are stored > in raw memory, then you wouldn't use a representation clause; you'd > let the compiler make any decisions about representation, subject to > the constraint that the code has to produce the right answers. > > But if you *do* provide a representation clause, then the > representation clearly *does* matter. And if the compiler can't > satisfy the requested representation (e.g., because two representation > clauses contradict each other), then the compiler should reject the > compilation unit. >- Hide quoted text - > > - Show quoted text - So that's why I'm wondering why compiler writers ever introduced biased representations in the first place. I can't believe that the problem with this approach has only been noticed in 2008. Aren't biased representations fundamentally incompatible with "the representation clearly *does* matter"? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 13:31 ` Mike Silva @ 2008-06-13 14:45 ` Markus Schoepflin 2008-06-13 17:52 ` Keith Thompson 1 sibling, 0 replies; 42+ messages in thread From: Markus Schoepflin @ 2008-06-13 14:45 UTC (permalink / raw) Mike Silva wrote: > So that's why I'm wondering why compiler writers ever introduced biased > representations in the first place. I can't believe that the problem > with this approach has only been noticed in 2008. In the project where I was bitten by this, it is clearly not the first time that this problem has occurred. In my search for other occurrences of the problem in the full source code (a few million SLOC) of the system, I discovered an old comment dating back from 1996, indicating that they had the same issue back then. > Aren't biased representations fundamentally incompatible with "the > representation clearly *does* matter"? From my point of view, biased representations and representation clauses should be mutually exclusive. Whenever I care enough about the representation that I think it necessary to write a representation clause, the compiler shouldn't fiddle with that representation behind my back. Markus ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 13:31 ` Mike Silva 2008-06-13 14:45 ` Markus Schoepflin @ 2008-06-13 17:52 ` Keith Thompson 1 sibling, 0 replies; 42+ messages in thread From: Keith Thompson @ 2008-06-13 17:52 UTC (permalink / raw) Mike Silva <snarflemike@yahoo.com> writes: > On Jun 13, 3:21�am, Keith Thompson <ks...@mib.org> wrote: >> Mike Silva <snarflem...@yahoo.com> writes: >> > On Jun 12, 2:41�pm, Markus Sch�pflin <nos...@nospam.org> wrote: >> >> Mike Silva schrieb: >> [...] >> >> > Are you saying now that there's no problem after all? >> >> >> Not at all. The memory layout of the variables is not what I expect it >> >> to be, because the compiler silently biased those values. The compiler >> >> is perfectly aware of this, as it makes up for the biasing when >> >> explicitly querying the value, but this doesn't help at all because I'm >> >> interested in the exact bitwise representation. >> >> >> Admittedly, there is an inconsistency in what I'm asking the compiler to >> >> do, but that's the whole point: I do not want this inconsistency to be >> >> silently 'fixed' by the compiler, I want to get noted about my error to >> >> get a chance and fix it myself. >> >> > I wonder then if this is an error at all. �IANALL, but if the program >> > makes available your specified values when queried with the proper >> > mechanism (in this case, unchecked conversion), then I don't see what >> > difference it makes how it stores the representations in raw memory. >> >> > I'd welcome other comments on the validity or non-validity of this >> > view. >> >> If it doesn't make any difference how the representations are stored >> in raw memory, then you wouldn't use a representation clause; you'd >> let the compiler make any decisions about representation, subject to >> the constraint that the code has to produce the right answers. >> >> But if you *do* provide a representation clause, then the >> representation clearly *does* matter. �And if the compiler can't >> satisfy the requested representation (e.g., because two representation >> clauses contradict each other), then the compiler should reject the >> compilation unit. >> > So that's why I'm wondering why compiler writers ever introduced > biased representations in the first place. I can't believe that the > problem with this approach has only been noticed in 2008. Aren't > biased representations fundamentally incompatible with "the > representation clearly *does* matter"? Oh, I see what you mean (I was missing your point). Hmm. Using a biased representation when the user has specified the exact representation via an enumeration representation clause seems clearly wrong. My thought was that a biased representation is perfectly ok if the user didn't specify the representation. The point I missed is that a biased representation is going to be used only if the user asked for something to be smaller than it would ordinarily be. So the question is, if I have something with range 100..101, and I use a record representation clause to request that it be stored in 1 bit, is it ok to use a biased representation, mapping 100 to 0 and 101 to 1? I think I'd still argue that it's ok, since I only specified one particular aspect of the representation, namely the number of bits. I didn't specify that 100 be represented as the bit sequence 1100100, and 101 as the bit sequence 1100101 (partly because there's no mechanism to specify that). If the compiler is able to generate code that gets the right answers *and* that satisfies those aspects of the representation that I specified, that's (at least arguably) ok. But I'd still say that a warning is appropriate, so that if I really do want an unbiased representation I can change the clause to allocate at least 7 bits. Using a biased representation in the presence of pragma Pack is perhaps another question. In that case, I've only specified minimal size, and deliberately refrained from specifying the details. But always warning about biased representations isn't a bad idea anyway. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 20:10 ` Mike Silva 2008-06-12 20:52 ` Simon Wright 2008-06-13 7:21 ` Keith Thompson @ 2008-06-13 9:14 ` Jean-Pierre Rosen 2 siblings, 0 replies; 42+ messages in thread From: Jean-Pierre Rosen @ 2008-06-13 9:14 UTC (permalink / raw) Mike Silva a �crit : > I wonder then if this is an error at all. IANALL, but if the program > makes available your specified values when queried with the proper > mechanism (in this case, unchecked conversion), then I don't see what > difference it makes how it stores the representations in raw memory. > > I'd welcome other comments on the validity or non-validity of this > view. > It would be interesting to add a pragma Volatile to the variable. It's a way of saying that you are serious about what's written in memory... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-11 11:38 Enumeration representation clause surprise Markus Schoepflin 2008-06-11 12:30 ` christoph.grein @ 2008-06-12 19:05 ` richtmyer 2008-06-12 21:26 ` Samuel Tardieu 1 sibling, 1 reply; 42+ messages in thread From: richtmyer @ 2008-06-12 19:05 UTC (permalink / raw) On Jun 11, 7:38 am, Markus Schoepflin <nos...@no.spam> wrote: > Hello, > > please consider the following code snippet: etc ----- Interesting. I had been playing with a similar example, and have modified it a bit to present. What got me is the record type with length 1 but an object with that type that was length zero! (It compiles without any warnings). ------------------------------ test1.2.ada -------------------------------------- -- -- GPS 4.2.1 (20080115) hosted on pentium-mingw32msv -- GNAT GPL 2007 (20070405-41) -- -- X_Type'size = 31 -- X_Rec_Type'size = 32 -- X_Rec'size = 32 -- Y_Rec_Type'size = 1 -- Y_Rec'size = 8 -- X_Rec.X1 = 2147483647 -- Y_Rec.X1 = 2147483647 -- GPS Pro 4.1.1 (20070423) hosted on i686-pc-linux-gnu -- GNAT Pro 6.1.1 (20080111-41) -- -- X_Type'size = 31 -- X_Rec_Type'size = 32 -- X_Rec'size = 32 -- Y_Rec_Type'size = 1 -- Y_Rec'size = 0 -- this object is smaller than its type! -- X_Rec.X1 = 2147483647 -- Y_Rec.X1 = 2147483647 ------------------------------------------------------------------------- with ada.exceptions; use ada.exceptions; with interfaces.c; with text_io; use text_io; with unchecked_conversion; procedure test1 is type X_Type is ( X ); for x_type use (x => 16#7FFF_FFFF#); type X_Rec_Type is Record X1 : X_Type; End Record; X_Rec : X_Rec_Type := (X1 => x); type Y_Rec_Type is Record X1 : X_Type; End Record; for Y_Rec_Type'size use 0; for Y_Rec_Type use Record X1 at 0 range 0 .. -1; -- Minus 1 !! End Record; Y_Rec : Y_Rec_Type := (X1 => X); function convert is new unchecked_conversion (X_type, natural); begin put_line("X_Type'size = " & X_Type'size'img); put_line("X_Rec_Type'size = " & X_Rec_Type'size'img); put_line("X_Rec'size = " & X_Rec'size'img); put_line("Y_Rec_Type'size = " & Y_Rec_Type'size'img); put_line("Y_Rec'size = " & Y_Rec'size'img); put_line("X_Rec.X1 = " & convert(X_Rec.X1)'img); put_line("Y_Rec.X1 = " & convert(Y_Rec.X1)'img); end test1; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 19:05 ` richtmyer @ 2008-06-12 21:26 ` Samuel Tardieu 2008-06-12 22:42 ` Adam Beneschan 2008-06-13 8:24 ` Peter Hermann 0 siblings, 2 replies; 42+ messages in thread From: Samuel Tardieu @ 2008-06-12 21:26 UTC (permalink / raw) > Interesting. I had been playing with a similar example, and have > modified it a bit to present. What got me is the record type with > length 1 but an object with that type that was length zero! The only possible value for X_Type is X. This requires 0 bit of information to represent this fact. > (It compiles without any warnings). With the proposed patch, it gives: GNAT 4.4.0 20080611 (experimental) Copyright 1992-2008, Free Software Foundation, Inc. Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24) 26. X1 at 0 range 0 .. -1; -- Minus 1 !! | >>> warning: component representation will be biased 42 lines: No errors, 1 warning ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 21:26 ` Samuel Tardieu @ 2008-06-12 22:42 ` Adam Beneschan 2008-06-13 7:11 ` Samuel Tardieu 2008-06-13 8:27 ` christoph.grein 2008-06-13 8:24 ` Peter Hermann 1 sibling, 2 replies; 42+ messages in thread From: Adam Beneschan @ 2008-06-12 22:42 UTC (permalink / raw) On Jun 12, 2:26 pm, Samuel Tardieu <s...@rfc1149.net> wrote: > > Interesting. I had been playing with a similar example, and have > > modified it a bit to present. What got me is the record type with > > length 1 but an object with that type that was length zero! > > The only possible value for X_Type is X. This requires 0 bit of > information to represent this fact. > > > (It compiles without any warnings). > > With the proposed patch, it gives: > > GNAT 4.4.0 20080611 (experimental) > Copyright 1992-2008, Free Software Foundation, Inc. > > Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24) > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > | > >>> warning: component representation will be biased So what would the value of the bias be? -- Adam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 22:42 ` Adam Beneschan @ 2008-06-13 7:11 ` Samuel Tardieu 2008-06-13 8:27 ` christoph.grein 1 sibling, 0 replies; 42+ messages in thread From: Samuel Tardieu @ 2008-06-13 7:11 UTC (permalink / raw) > > Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24) > > > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > > | > > >>> warning: component representation will be biased > > So what would the value of the bias be? Yes, I've noticed too that the error message could be improved in this particular case, as here "biased" means "different from what you might expect". ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 22:42 ` Adam Beneschan 2008-06-13 7:11 ` Samuel Tardieu @ 2008-06-13 8:27 ` christoph.grein 2008-06-13 16:21 ` Adam Beneschan 1 sibling, 1 reply; 42+ messages in thread From: christoph.grein @ 2008-06-13 8:27 UTC (permalink / raw) > > With the proposed patch, it gives: > > > GNAT 4.4.0 20080611 (experimental) > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > > | > > >>> warning: component representation will be biased > > So what would the value of the bias be? type X_Type is ( X ); for x_type use (x => 16#7FFF_FFFF#); 16#7FFF_FFFF# of course Since this is the only value, nothing need be stored to know which value it is. This is like a constant in ROM, I gather. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 8:27 ` christoph.grein @ 2008-06-13 16:21 ` Adam Beneschan 2008-06-15 19:33 ` Robert A Duff 0 siblings, 1 reply; 42+ messages in thread From: Adam Beneschan @ 2008-06-13 16:21 UTC (permalink / raw) On Jun 13, 1:27 am, christoph.gr...@eurocopter.com wrote: > > > With the proposed patch, it gives: > > > > GNAT 4.4.0 20080611 (experimental) > > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > > > | > > > >>> warning: component representation will be biased > > > So what would the value of the bias be? > > type X_Type is ( X ); > for x_type use (x => 16#7FFF_FFFF#); > > 16#7FFF_FFFF# of course > > Since this is the only value, nothing need be stored to know which > value it is. This is like a constant in ROM, I gather. My point is that the "bias" is the difference between the (conceptual) value being represented, and the number actually stored in memory. So what number is stored in a 0-bit data item? I suppose you could arbitrarily decide it's zero (which would make some sense mathematically) but it seems more commonsensical to say that nothing is stored there because there ain't no bits to store anything in. -- Adam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 16:21 ` Adam Beneschan @ 2008-06-15 19:33 ` Robert A Duff 2008-06-16 14:50 ` Adam Beneschan 0 siblings, 1 reply; 42+ messages in thread From: Robert A Duff @ 2008-06-15 19:33 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: >...So > what number is stored in a 0-bit data item? Zero. An n-bit field is either signed or unsigned. When you load the field into a register, you take all the bits and add copies of the sign bit on the left (for signed) or zeros on the left (for unsigned). A 0-bit field must be unsigned (there's no sign bit!). So you take nothing, and add 32 zero bits on the left (on a 32-bit machine). Or you could think of it as an infinitely-long string of bits -- you sign extend or zero extend infinitely on the left to get the value. Then of course you can bias that 0 by anything -- range 100..100 can be stored in a zero-bit unsigned bitfield, biased by 100. (Or is that -100?) >...I suppose you could > arbitrarily decide it's zero (which would make some sense > mathematically) Yes, I think so. >... but it seems more commonsensical to say that nothing > is stored there because there ain't no bits to store anything in. But that view requires a special case. The natural unsigned range for n bits, where n >= 0, is 0..(2**n)-1. Which is 0..0 when n = 0. The natural signed (2's complement) range for n bits, where n > 0, is -(2**(n-1))..(2**(n-1))-1. Which makes no sense if n = 0, because we don't want to mess around with negative exponents (fractions) -- we're talking about integer ranges. - Bob ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-15 19:33 ` Robert A Duff @ 2008-06-16 14:50 ` Adam Beneschan 2008-06-16 19:18 ` Robert A Duff 2008-06-17 6:03 ` christoph.grein 0 siblings, 2 replies; 42+ messages in thread From: Adam Beneschan @ 2008-06-16 14:50 UTC (permalink / raw) On Jun 15, 12:33 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: > Adam Beneschan <a...@irvine.com> writes: > >...I suppose you could > > arbitrarily decide it's zero (which would make some sense > > mathematically) > > Yes, I think so. > > >... but it seems more commonsensical to say that nothing > > is stored there because there ain't no bits to store anything in. > > But that view requires a special case. > > The natural unsigned range for n bits, where n >= 0, > is 0..(2**n)-1. Which is 0..0 when n = 0. Right, that does make sense. I'm not convinced it matters, since all this mathematics isn't necessariliy going to be self-evident to a poor user. This particular subthread was about a warning message that, I think, could leave the user scratching their head about what it means, and that isn't a good thing regardless of how sound is the mathematics on which the warning is based. -- Adam ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-16 14:50 ` Adam Beneschan @ 2008-06-16 19:18 ` Robert A Duff 2008-06-17 6:03 ` christoph.grein 1 sibling, 0 replies; 42+ messages in thread From: Robert A Duff @ 2008-06-16 19:18 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: >...This particular subthread was about a warning message that, I > think, could leave the user scratching their head about what it means, > and that isn't a good thing regardless of how sound is the mathematics > on which the warning is based. Agreed. - Bob ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-16 14:50 ` Adam Beneschan 2008-06-16 19:18 ` Robert A Duff @ 2008-06-17 6:03 ` christoph.grein 2008-06-17 7:22 ` christoph.grein 1 sibling, 1 reply; 42+ messages in thread From: christoph.grein @ 2008-06-17 6:03 UTC (permalink / raw) GNAT supports all annexes. So note C.2(2). From this it follows via 13.3(55,55.b) that U'Size must be 0 for an unsigned integer subtype U with range 0 .. 1 only. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-17 6:03 ` christoph.grein @ 2008-06-17 7:22 ` christoph.grein 0 siblings, 0 replies; 42+ messages in thread From: christoph.grein @ 2008-06-17 7:22 UTC (permalink / raw) On 17 Jun., 08:03, christoph.gr...@eurocopter.com wrote: > GNAT supports all annexes. > > So note C.2(2). From this it follows via 13.3(55,55.b) that U'Size > must be 0 for an unsigned integer subtype U with range 0 .. 0 only. Of course I meant upper bound 0. The same should be true for a biased representation of a range with one value only. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-12 21:26 ` Samuel Tardieu 2008-06-12 22:42 ` Adam Beneschan @ 2008-06-13 8:24 ` Peter Hermann 2008-06-13 14:47 ` Samuel Tardieu 1 sibling, 1 reply; 42+ messages in thread From: Peter Hermann @ 2008-06-13 8:24 UTC (permalink / raw) Samuel Tardieu <sam@rfc1149.net> wrote: > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! this is a null range: LRM3.5(4) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 8:24 ` Peter Hermann @ 2008-06-13 14:47 ` Samuel Tardieu 2008-06-14 11:48 ` John B. Matthews 0 siblings, 1 reply; 42+ messages in thread From: Samuel Tardieu @ 2008-06-13 14:47 UTC (permalink / raw) Peter Hermann: > Samuel Tardieu <sam@rfc1149.net> wrote: > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > > this is a null range: LRM3.5(4) Exactly. And this null range can represent 2^0 = 1 value. Which is the case in this example. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Enumeration representation clause surprise. 2008-06-13 14:47 ` Samuel Tardieu @ 2008-06-14 11:48 ` John B. Matthews 0 siblings, 0 replies; 42+ messages in thread From: John B. Matthews @ 2008-06-14 11:48 UTC (permalink / raw) In article <878wx9bdda.fsf@willow.rfc1149.net>, Samuel Tardieu <sam@rfc1149.net> wrote: > Peter Hermann: > > > Samuel Tardieu <sam@rfc1149.net> wrote: > > > 26. X1 at 0 range 0 .. -1; -- Minus 1 !! > > > > this is a null range: LRM3.5(4) > > Exactly. And this null range can represent 2^0 = 1 value. Which is the > case in this example. But null (o, \u00F8) is not zero. The range 0 .. -1 is "a null range, and [it] specifies an empty set of values." [LRM3.5(4)] If I understand it correctly, the value 2^0 is the power set of o, {o}, a set with one element, which is the empty set. John -- John B. Matthews trashgod at gmail dot com home dot woh dot rr dot com slash jbmatthews ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2008-06-17 7:22 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-06-11 11:38 Enumeration representation clause surprise Markus Schoepflin 2008-06-11 12:30 ` christoph.grein 2008-06-11 12:56 ` Markus Schoepflin 2008-06-11 13:08 ` christoph.grein 2008-06-11 13:28 ` Samuel Tardieu 2008-06-11 13:48 ` Markus Schoepflin 2008-06-11 13:56 ` Samuel Tardieu 2008-06-11 14:58 ` Adam Beneschan 2008-06-11 15:23 ` Markus Schoepflin 2008-06-12 2:37 ` Randy Brukardt 2008-06-12 2:37 ` Randy Brukardt 2008-06-11 15:56 ` Samuel Tardieu 2008-06-11 19:10 ` Adam Beneschan 2008-06-11 19:59 ` Niklas Holsti 2008-06-12 1:16 ` tmoran 2008-06-12 8:27 ` christoph.grein 2008-06-12 8:45 ` Markus Schoepflin 2008-06-12 16:43 ` Mike Silva 2008-06-12 18:41 ` Markus Schöpflin 2008-06-12 20:10 ` Mike Silva 2008-06-12 20:52 ` Simon Wright 2008-06-12 23:36 ` Mike Silva 2008-06-13 5:49 ` Simon Wright 2008-06-13 7:21 ` Keith Thompson 2008-06-13 13:31 ` Mike Silva 2008-06-13 14:45 ` Markus Schoepflin 2008-06-13 17:52 ` Keith Thompson 2008-06-13 9:14 ` Jean-Pierre Rosen 2008-06-12 19:05 ` richtmyer 2008-06-12 21:26 ` Samuel Tardieu 2008-06-12 22:42 ` Adam Beneschan 2008-06-13 7:11 ` Samuel Tardieu 2008-06-13 8:27 ` christoph.grein 2008-06-13 16:21 ` Adam Beneschan 2008-06-15 19:33 ` Robert A Duff 2008-06-16 14:50 ` Adam Beneschan 2008-06-16 19:18 ` Robert A Duff 2008-06-17 6:03 ` christoph.grein 2008-06-17 7:22 ` christoph.grein 2008-06-13 8:24 ` Peter Hermann 2008-06-13 14:47 ` Samuel Tardieu 2008-06-14 11:48 ` John B. Matthews
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox