* Boolean Representation @ 1998-09-24 0:00 matthew_snyder 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` dewarr 0 siblings, 2 replies; 29+ messages in thread From: matthew_snyder @ 1998-09-24 0:00 UTC (permalink / raw) Is it safe to make the assumption that a boolean value of FALSE will always be represented as a 0 and a value of TRUE will always be represented as a 1? Will an unchecked conversion from a boolean to an integer always yield the same results with different compilers? Matthew Snyder matthew_snyder@hotmail.com -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 Boolean Representation matthew_snyder @ 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` Keith Thompson 1998-09-24 0:00 ` dewarr 1 sibling, 1 reply; 29+ messages in thread From: dennison @ 1998-09-24 0:00 UTC (permalink / raw) In article <6udkcj$87j$1@nnrp1.dejanews.com>, matthew_snyder@my-dejanews.com wrote: > Is it safe to make the assumption that a boolean value of FALSE will always > be represented as a 0 and a value of TRUE will always be represented as a 1? > Will an unchecked conversion from a boolean to an integer always yield the > same results with different compilers? I believe the only guarantee you get is that the value of True is larger than the value of False. To get the behavior you want portably, do a: Boolean'pos(Boolean_Variable) -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` dennison @ 1998-09-24 0:00 ` Keith Thompson 1998-09-25 0:00 ` dennison 0 siblings, 1 reply; 29+ messages in thread From: Keith Thompson @ 1998-09-24 0:00 UTC (permalink / raw) dennison@telepath.com writes: > In article <6udkcj$87j$1@nnrp1.dejanews.com>, [...] > I believe the only guarantee you get is that the value of True is larger than > the value of False. I don't believe even that much is guaranteed. A compiler I worked on used, for some targets, the representation (False => 0, True => -1) (i.e., a literal True value was represented with all bits set to 1 (2's-complement) rather than just the last bit set to 1). This made tests and logical operations more efficient, at the expense of some extra code for Boolean'Pos, Boolean'Val, "<", ">", etc. It's true that a user-defined enumeration representation clause cannot legally specify such a representation, but there's nothing preventing the compiler from doing so. Of course, for a 1-bit Boolean (a member of a packed array or record), this is equivalent to (False => 0, True => 1). I think the original question had to do with 1-bit Booleans. I suppose it's conceivable that some implementation might represent False as 1 and True as 0 in this context, but it would be perverse. If you really care about how the bits are set, it's probably safer to use modular types. > To get the behavior you want portably, do a: > > Boolean'pos(Boolean_Variable) Agreed. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` Keith Thompson @ 1998-09-25 0:00 ` dennison 1998-09-25 0:00 ` Keith Thompson 0 siblings, 1 reply; 29+ messages in thread From: dennison @ 1998-09-25 0:00 UTC (permalink / raw) In article <yecogs5gidf.fsf@king.cts.com>, Keith Thompson <kst@king.cts.com> wrote: > dennison@telepath.com writes: > > > In article <6udkcj$87j$1@nnrp1.dejanews.com>, > [...] > > I believe the only guarantee you get is that the value of True is larger than > > the value of False. > > I don't believe even that much is guaranteed. A compiler I worked on > used, for some targets, the representation (False => 0, True => -1) > (i.e., a literal True value was represented with all bits set to 1 > (2's-complement) rather than just the last bit set to 1). This made > tests and logical operations more efficient, at the expense of some > extra code for Boolean'Pos, Boolean'Val, "<", ">", etc. I suspect their claim would be: (False => 0, True => 2**32 - 1). -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-25 0:00 ` dennison @ 1998-09-25 0:00 ` Keith Thompson 1998-09-26 0:00 ` Tucker Taft 0 siblings, 1 reply; 29+ messages in thread From: Keith Thompson @ 1998-09-25 0:00 UTC (permalink / raw) dennison@telepath.com writes: > In article <yecogs5gidf.fsf@king.cts.com>, > Keith Thompson <kst@king.cts.com> wrote: [...] > > > > I don't believe even that much is guaranteed. A compiler I worked on > > used, for some targets, the representation (False => 0, True => -1) > > (i.e., a literal True value was represented with all bits set to 1 > > (2's-complement) rather than just the last bit set to 1). This made > > tests and logical operations more efficient, at the expense of some > > extra code for Boolean'Pos, Boolean'Val, "<", ">", etc. > > I suspect their claim would be: (False => 0, True => 2**32 - 1). > -- > T.E.D. No, no such claim is necessary. Also, this was an Ada-83 compiler with no unsigned types (and no integer types larger than 32 bits), so 2**32-1 wasn't even a legal value. False was represented as 0, True was represented as -1, and the compiler generated extra code where necessary to ensure that all the language-defined operations (Boolean'Pos, "<", ">=", Boolean'Image, etc.) worked as specified. The language forbids a user from specifying a non-increasing representation for an enumeration type, but it doesn't forbid an implementation from doing so for type Boolean. Here's another interesting question. Suppose some perverse implementation used an internal representation of (False => 1, True => 0) for type Boolean, and generated extra code to make all the predefined operations work properly. A packed array of 32 Booleans, for example, would occupy 32 bits, but setting it to (others => True) would clear all 32 bits. I'm not suggesting that this would ever be a good idea, but would it actually violate the RM? -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-25 0:00 ` Keith Thompson @ 1998-09-26 0:00 ` Tucker Taft 1998-09-26 0:00 ` Keith Thompson 1998-09-27 0:00 ` Boolean Representation dewarr 0 siblings, 2 replies; 29+ messages in thread From: Tucker Taft @ 1998-09-26 0:00 UTC (permalink / raw) Keith Thompson (kst@king.cts.com) wrote: : ... : Here's another interesting question. Suppose some perverse : implementation used an internal representation of (False => 1, True => 0) : for type Boolean, and generated extra code to make all the predefined : operations work properly. A packed array of 32 Booleans, for example, : would occupy 32 bits, but setting it to (others => True) would clear : all 32 bits. I'm not suggesting that this would ever be a good idea, : but would it actually violate the RM? It is just this kind of thinking which led people to put "reconfirming" representation clauses on enumeration types in Ada 83. What a waste of energy! We added a rule in Ada 95 to save the paranoid from writing all those silly enumeration representation clauses. I can see we should have gone one step further, specifying the representation for 1-bit boolean objects. Groan. Please paranoid readers, don't go worrying about the possibility of 1-bit boolean objects having False = 1. Instead, let's all agree to shun any Ada compiler which makes such an absurd choice... That's ultimately much more effective than any words in a standard. : -- : Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> : Qualcomm, San Diego, California, USA <http://www.qualcomm.com> -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-26 0:00 ` Tucker Taft @ 1998-09-26 0:00 ` Keith Thompson 1998-09-27 0:00 ` dewarr 1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr 1998-09-27 0:00 ` Boolean Representation dewarr 1 sibling, 2 replies; 29+ messages in thread From: Keith Thompson @ 1998-09-26 0:00 UTC (permalink / raw) stt@houdini.camb.inmet.com (Tucker Taft) writes: > It is just this kind of thinking which led people to put "reconfirming" > representation clauses on enumeration types in Ada 83. What a waste > of energy! We added a rule in Ada 95 to save the paranoid from > writing all those silly enumeration representation clauses. I can > see we should have gone one step further, specifying the representation > for 1-bit boolean objects. Groan. I really didn't mean to induce paranoia, and I agree it's not worth worrying about in the real world. > Please paranoid readers, don't go worrying about the possibility of > 1-bit boolean objects having False = 1. Instead, let's all agree > to shun any Ada compiler which makes such an absurd choice... That's > ultimately much more effective than any words in a standard. Fortunately, I seriously doubt that there will ever be any such compilers to shun. Sometimes, however, it's not 100% obvious which assumptions one should make. We can safely assume that a 1-bit Boolean uses (False => 0, True => 1), even though it's not spelled out in the RM. We *can't* safely assume that an 8-bit (or 32-bit, or whatever) Boolean uses (False => 0, True => 1) -- though we can *probably* assume that False is 0. Nor can we assume that a program exit status of 0 denotes success and 1 denotes failure, or that a floating-point 0.0 or a null pointer is represented as all-bits-zero, or that record components are laid out in the order in which they're declared -- though some programmers will insist on doing so. Fortunately Ada tends to make the need for such assumptions rare. (Sorry, I've been programming in C lately. I guess it's warped my mind a bit.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-26 0:00 ` Keith Thompson @ 1998-09-27 0:00 ` dewarr 1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr 1 sibling, 0 replies; 29+ messages in thread From: dewarr @ 1998-09-27 0:00 UTC (permalink / raw) In article <yec1zoyd2xa.fsf@king.cts.com>, Keith Thompson <kst@king.cts.com> wrote: > Sometimes, however, it's not 100% obvious which assumptions one should > make. We can safely assume that a 1-bit Boolean uses (False => 0, > True => 1), even though it's not spelled out in the RM. We *can't* > safely assume that an 8-bit (or 32-bit, or whatever) Boolean uses > (False => 0, True => 1) -- though we can *probably* assume that False > is 0. Nor can we assume that a program exit status of 0 denotes > success and 1 denotes failure, or that a floating-point 0.0 or a null > pointer is represented as all-bits-zero, or that record components are > laid out in the order in which they're declared -- though some > programmers will insist on doing so. No! That is going too far in the other direction, the 95 RM goes out of its way to tell you that you CANNOT *probably* assume this. You may assume nothing about the representaiton of Boolean, other than that it is ordered, considered either signed or as unsigned. For example, some safety critical implementation might use 0101 for False, and 1010 for True (see Brian Wichman's discussion of the advantages of this representation). Such a representation is just fine, and assuming that False is zero for other than a 1-bit representation (where there is no other reasonable choice), would be incorrect. It is not always easy to understand the boundary between what is reasonable and unreasonable, but I think it is easy enough in this case. Yes, I know that some formalist might claim: False = -1 True = 0 with a 1-bit twos complement representation, and indeed that shows that an AI probably *is* needed for formal reasons, but one cannot imagine a compiler choosing this. One can however, most certainly imagine a compiler that generates junk code for a "confirming" enum rep clause. Certainly not all compilers make this mistake (GNAT most certainly does not), but we have read here of real Ada 95 compilers that do make this mistake, so the best pragmatic approach is most certainly to avoid junk confirming rep clauses. Note that you may or may not be able to define a derived boolean and give a rep clause for it, that is non-portable impl-dependent coding. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* null pointer representation (was: Boolean Representation) 1998-09-26 0:00 ` Keith Thompson 1998-09-27 0:00 ` dewarr @ 1998-09-27 0:00 ` Arthur Evans Jr 1998-09-27 0:00 ` Keith Thompson 1998-09-28 0:00 ` dewarr 1 sibling, 2 replies; 29+ messages in thread From: Arthur Evans Jr @ 1998-09-27 0:00 UTC (permalink / raw) In article <yec1zoyd2xa.fsf@king.cts.com>, Keith Thompson <kst@king.cts.com> wrote: > Nor can we assume that a ... null pointer is represented as all-bits-zero Indeed not. Some years ago I was concerned about this very issue and asked around (probably on cla) about it. The answers were instructive. Most compilers did in fact use all zeros, but some other values were used, including one compiler (from IBM, I think) that used the HEX number DEAD BEEF. I suppose it really stood out in HEX dumps. Since I was interfacing to C-code in Ada-83 and code on the C side needed zero for null pointers, I ended up writing some extra code to ensure that value, even though the implementation I was then using represented the null pointer as zero. And then we never ported to another compiler, so that effort was wasted. Well, them's the breaks. Art Evans Make the obvious fix to my address. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr @ 1998-09-27 0:00 ` Keith Thompson 1998-09-28 0:00 ` dewarr 1 sibling, 0 replies; 29+ messages in thread From: Keith Thompson @ 1998-09-27 0:00 UTC (permalink / raw) evans@evans.pgh.pa.us (Arthur Evans Jr) writes: > In article <yec1zoyd2xa.fsf@king.cts.com>, > Keith Thompson <kst@king.cts.com> wrote: > > > Nor can we assume that a ... null pointer is represented as all-bits-zero > > Indeed not. Some years ago I was concerned about this very issue and > asked around (probably on cla) about it. The answers were instructive. > Most compilers did in fact use all zeros, but some other values were > used, including one compiler (from IBM, I think) that used the HEX > number DEAD BEEF. I suppose it really stood out in HEX dumps. > > Since I was interfacing to C-code in Ada-83 and code on the C side > needed zero for null pointers, I ended up writing some extra code to > ensure that value, even though the implementation I was then using > represented the null pointer as zero. Incidentally (and only slightly off-topic), C also does not guarantee that a null pointer is represented as all-bits-zero. There's enough C code out there that assumes that it is that almost all C compilers use the "expected" representation, but there's no such requirement. (The issue is further confused by the fact that the source representation of a C null pointer is an integer literal 0.) See the comp.lang.c FAQ for an extensive discussion of this. Getting back to Ada, I was a little surprised to see that the generic package Interfaces.C.Pointers doesn't explicitly declare a constant corresponding to a C NULL pointer, but this should be covered by the statement that the type Pointer is C-compatible. So Ada 95 programmers shouldn't have to worry about it as long as they use the interfacing features provided by the language. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr 1998-09-27 0:00 ` Keith Thompson @ 1998-09-28 0:00 ` dewarr 1998-09-28 0:00 ` Lieven Marchand 1998-09-28 0:00 ` Keith Thompson 1 sibling, 2 replies; 29+ messages in thread From: dewarr @ 1998-09-28 0:00 UTC (permalink / raw) In article <evans-2709981430360001@ppp23.s9.pgh.net>, evans@evans.pgh.pa.us (Arthur Evans Jr) wrote: > In article <yec1zoyd2xa.fsf@king.cts.com>, > Keith Thompson <kst@king.cts.com> wrote: > > > Nor can we assume that a ... null pointer is represented as all-bits-zero > > Indeed not. Some years ago I was concerned about this very issue and > asked around (probably on cla) about it. The answers were instructive. > Most compilers did in fact use all zeros, but some other values were > used, including one compiler (from IBM, I think) that used the HEX > number DEAD BEEF. I suppose it really stood out in HEX dumps. Art, I think this memory is wrong. At least in compilers I have seen, it is indeed common to use DEAD BEEF for uninitialized variables, but I have not seen it used for null pointers. If someone knows a counter example, I would be interested. Certainly though, you are right, Null_Address can be assumed to be all zero bits in practice, but not Null. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-28 0:00 ` dewarr @ 1998-09-28 0:00 ` Lieven Marchand 1998-09-28 0:00 ` Keith Thompson 1 sibling, 0 replies; 29+ messages in thread From: Lieven Marchand @ 1998-09-28 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > Art, I think this memory is wrong. At least in compilers I have seen, it is > indeed common to use DEAD BEEF for uninitialized variables, but I have not > seen it used for null pointers. If someone knows a counter example, I would > be interested. Question 5.17 in the comp.lang.c FAQ. -- Lieven Marchand <mal@bewoner.dma.be> ------------------------------------------------------------------------------ Few people have a talent for constructive laziness. -- Lazarus Long ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-28 0:00 ` dewarr 1998-09-28 0:00 ` Lieven Marchand @ 1998-09-28 0:00 ` Keith Thompson 1998-09-28 0:00 ` dewarr 1 sibling, 1 reply; 29+ messages in thread From: Keith Thompson @ 1998-09-28 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: [...] > Certainly though, you are right, Null_Address can be assumed to be all > zero bits in practice, but not Null. Why is it safe to assume that Null_Address is all zero bits? I'd normally expect it to have the same representation as a null pointer, though of course that's not guaranteed either. (In any case, since Null_Address is conveniently declared in System, there's no need to assume anything about how it's represented.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-28 0:00 ` Keith Thompson @ 1998-09-28 0:00 ` dewarr 1998-09-30 0:00 ` Keith Thompson 0 siblings, 1 reply; 29+ messages in thread From: dewarr @ 1998-09-28 0:00 UTC (permalink / raw) In article <yecu31su3gj.fsf@king.cts.com>, Keith Thompson <kst@king.cts.com> wrote: > dewarr@my-dejanews.com writes: > [...] > > Certainly though, you are right, Null_Address can be assumed to be all > > zero bits in practice, but not Null. > > Why is it safe to assume that Null_Address is all zero bits? > I'd normally expect it to have the same representation as a null > pointer, though of course that's not guaranteed either. > > (In any case, since Null_Address is conveniently declared in System, > there's no need to assume anything about how it's represented.) What is and is not safe to assume cannot be derived only from ISO standards! For all sorts of reasons, it is safe to assume that Null_Address is all zero bits. If you think this is wrong, cough up a counter example :-) Still, of course it is better never to have to depend on this assumption if you can avoid it (the same comment applies exactly equivalently to C code) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-28 0:00 ` dewarr @ 1998-09-30 0:00 ` Keith Thompson 1998-10-02 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 29+ messages in thread From: Keith Thompson @ 1998-09-30 0:00 UTC (permalink / raw) I posted a followup to this the other day, based on a misunderstanding of what Robert had written (I somehow managed to read "cannot" as "can"). I tried to cancel it; if the cancel didn't work, please ignore my previous followup. dewarr@my-dejanews.com writes: > What is and is not safe to assume cannot be derived only from ISO standards! > For all sorts of reasons, it is safe to assume that Null_Address is all > zero bits. If you think this is wrong, cough up a counter example :-) There are real systems out there on which the underlying operating system uses a value other than all-bits-zero for null pointers. As someone else pointed out, several examples can be found in question 5.17 of the C FAQ. On such a system, it would make perfect sense for System.Null_Address to use the system's non-zero representation for a null pointer. A C compiler on such a system would very likely use all-bits-zero to cater to poorly written existing code, but there's no need for an Ada compiler to do so. Even if there weren't any such machines, I don't believe that the assumption that System.Null_Address is all zero bits would be justified -- though admittedly my argument would be a bit weaker. > Still, of course it is better never to have to depend on this assumption > if you can avoid it (the same comment applies exactly equivalently to C code) Agreed. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> It takes a Viking to raze a village. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: null pointer representation (was: Boolean Representation) 1998-09-30 0:00 ` Keith Thompson @ 1998-10-02 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 29+ messages in thread From: Robert I. Eachus @ 1998-10-02 0:00 UTC (permalink / raw) In article <yec1zotnlor.fsf@king.cts.com> Keith Thompson <kst@king.cts.com> writes: > Even if there weren't any such machines, I don't believe that the > assumption that System.Null_Address is all zero bits would be > justified -- though admittedly my argument would be a bit weaker. Some years back at Stratus, we used one not zero as the value for null pointers, since it trapped if dereferenced. When the 68020 came along, we temporarily switched to xFFFFFFFF (I don't think that version ever shipped.) Then to a version of the OS where page zero was inaccessable in user mode so that we could use zero as a null address in user code. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-26 0:00 ` Tucker Taft 1998-09-26 0:00 ` Keith Thompson @ 1998-09-27 0:00 ` dewarr 1 sibling, 0 replies; 29+ messages in thread From: dewarr @ 1998-09-27 0:00 UTC (permalink / raw) In article <Ezw8Et.57H.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > It is just this kind of thinking which led people to put "reconfirming" > representation clauses on enumeration types in Ada 83. What a waste > of energy! We added a rule in Ada 95 to save the paranoid from > writing all those silly enumeration representation clauses. I can > see we should have gone one step further, specifying the representation > for 1-bit boolean objects. Groan. No, I don't think such a rule is necessary, it is clearly the intention of the RM that one bit boolean representations are like all other enumeration representations in that the representations must be ordered. Remember that when you read the RM, just because you manage to find a reading that confirms something absurd does not mean that Ada allows absurd things. After all, any possible reading of the Ada 83 RM that is done in this uninformed style will tell you that virtually no subtypes are static, e.g. subtype x is integer range 1 .. 10; is not a static subtype. But this never actually bothered anyone, except the ARG who had to waste a few minutes fixing the RM for the record. I am not even sure that this particular issue (one bit boolean must have rep 0/1) needs an AI. If it does, fine the ARG will issue one, but like many many AI's this AI will have absolutely zero impact on any real user of Ada unless they fail to understand the dynamics of the language definition. After all, remember that there is nothing in the RM to stop an implementation from using a loop with serial addition to implement multiplication, but even the paranoid among Ada users do not eschew multiplication because of this. You have to have some sense of the reasonable when using any language! Even if you have a formal definition of a language, there can be errors in the definition. If a typo in the formal definition ends up resulting in an implication that "<" means ">" all this means is that there is an error in the formal definition, not in the language being defined! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 Boolean Representation matthew_snyder 1998-09-24 0:00 ` dennison @ 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Samuel T. Harris 1998-09-24 0:00 ` matthew_snyder 1 sibling, 2 replies; 29+ messages in thread From: dewarr @ 1998-09-24 0:00 UTC (permalink / raw) In article <6udkcj$87j$1@nnrp1.dejanews.com>, matthew_snyder@my-dejanews.com wrote: > Is it safe to make the assumption that a boolean value of FALSE will always > be represented as a 0 and a value of TRUE will always be represented as a 1? > Will an unchecked conversion from a boolean to an integer always yield the > same results with different compilers? Whether true or false, this is junky coding, just use Boolean'Pos (val) to get 0 or 1 in a for sure portable manner. Remember that to use an unchecked conversion for Boolean, you would have to use a 1-bit integer, anything else most definitely gives an implementation defined result. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` dewarr @ 1998-09-24 0:00 ` Samuel T. Harris 1998-09-25 0:00 ` dewarr 1998-09-24 0:00 ` matthew_snyder 1 sibling, 1 reply; 29+ messages in thread From: Samuel T. Harris @ 1998-09-24 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: > > In article <6udkcj$87j$1@nnrp1.dejanews.com>, > matthew_snyder@my-dejanews.com wrote: > > Is it safe to make the assumption that a boolean value of FALSE will always > > be represented as a 0 and a value of TRUE will always be represented as a 1? > > Will an unchecked conversion from a boolean to an integer always yield the > > same results with different compilers? > > Whether true or false, this is junky coding, just use > Boolean'Pos (val) to get 0 or 1 in a for sure portable > manner. Remember that to use an unchecked conversion for > Boolean, you would have to use a 1-bit integer, anything > else most definitely gives an implementation defined result. > Good advice. In general I also am not concerned with the internal representations of enumeration literals. I'm usually concerned only with their order and the fact that each has a unique ordinal within its type. However, I have had occasion to be concerned with the actual internal representation. This is where enumeration representation clauses come in handy. Specifically, I have had to represent a memory-mapped device with an Ada record. One of the fields was a 16-bit flag array. A packed array of booleans fit nicely. However, to insure the boolean literals FALSE and TRUE have the appropriate internal numbers, I used a derived type of boolean to which I applied the appropriate representation clause. I know that this might sound a bit paranoid but I tend to favor ultra-correctness over any reliance on common compiler implementations. -- Samuel T. Harris, Principal Engineer Raytheon Training Incorporated "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` Samuel T. Harris @ 1998-09-25 0:00 ` dewarr 1998-09-27 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 29+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <360A8CCB.2D358953@hso.link.com>, "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > However, I have had occasion to be concerned with the > actual internal representation. This is where enumeration > representation clauses come in handy. Specifically, I have > had to represent a memory-mapped device with an Ada record. > One of the fields was a 16-bit flag array. A packed array > of booleans fit nicely. However, to insure the boolean > literals FALSE and TRUE have the appropriate internal > numbers, I used a derived type of boolean to which I applied > the appropriate representation clause. I know that this > might sound a bit paranoid but I tend to favor ultra-correctness > over any reliance on common compiler implementations. There is a difference between relying on common compiler implementations, and relying on the RM. In fact the above described technique is significantly non-portable because of 13.4(10) 10 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. On the other hand, obviously if a boolean is stored in one bit, False must be zero and True must be one, because absolute ordering is required. Your paranoia here is leading you astray into completely unnecessary and significantly implementation dependent coding! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-25 0:00 ` dewarr @ 1998-09-27 0:00 ` Samuel T. Harris 1998-09-28 0:00 ` dewar 0 siblings, 1 reply; 29+ messages in thread From: Samuel T. Harris @ 1998-09-27 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: > > In article <360A8CCB.2D358953@hso.link.com>, > "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > > However, I have had occasion to be concerned with the > > actual internal representation. This is where enumeration > > representation clauses come in handy. Specifically, I have > > had to represent a memory-mapped device with an Ada record. > > One of the fields was a 16-bit flag array. A packed array > > of booleans fit nicely. However, to insure the boolean > > literals FALSE and TRUE have the appropriate internal > > numbers, I used a derived type of boolean to which I applied > > the appropriate representation clause. I know that this > > might sound a bit paranoid but I tend to favor ultra-correctness > > over any reliance on common compiler implementations. > > There is a difference between relying on common compiler > implementations, and relying on the RM. > > In fact the above described technique is significantly > non-portable because of 13.4(10) > > 10 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. As to portability, any compiler which does not support the Chapter 13 features _required_ is simply not a candidate compiler for the project. Indeed, having the representation clause present insures an explicit "compatibility" test when evaluating a new compiler. If the compiler does not support the representation clause, then I'll know it the first time I try to compile it. In this particular case, any compiler complaining about the representation clause _may_ be a candidate if its default behavior is satisfactory to the problem at hand. The represenation clause can be commented out with additional commentary inserted explaining the reliance on the compiler's default representation. The extra commentary is not necessarily for the programmers (who should know how their compiler behaves) but for any representatives of the hardware being interfaced who probably do not know Ada very well but are present at design and code reviews. > > On the other hand, obviously if a boolean is stored in one > bit, False must be zero and True must be one, because > absolute ordering is required. > I don't see anything in the RM which makes this a "must" proposition. I have been burned many times by trusting compilers' use "common sense" implementations, GNAT included. > Your paranoia here is leading you astray into completely > unnecessary and significantly implementation dependent > coding! > I contend that relying upon default compiler representations is "significantly implementation dependent coding", especially when the representations matter so much. When interfacing to hardwary, my policy is to assume nothing and to leave nothing to chance. -- Samuel T. Harris, Principal Engineer Raytheon Training Incorporated "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-27 0:00 ` Samuel T. Harris @ 1998-09-28 0:00 ` dewar 0 siblings, 0 replies; 29+ messages in thread From: dewar @ 1998-09-28 0:00 UTC (permalink / raw) In article <360E9B5E.FF081471@hso.link.com>, "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > As to portability, any compiler which does not support > the Chapter 13 features _required_ is simply not a candidate > compiler for the project. Indeed, having the representation > clause present insures an explicit "compatibility" test > when evaluating a new compiler. If the compiler does > not support the representation clause, then I'll know > it the first time I try to compile it. That is reasonable as a general policy, but I will repeat that it is misapplied here. Given the two choices: 1. Count on a one-bit Boolean having representation 0 for False, and 1 for True. 2. Deriving from Boolean, and applying a rep clause. It is clear that both from a pragmatic point of view and a formal RM point of view, 1. is far superior, and 2. is as far as I am concerned just wrong. From an RM point of view, you should not rely on non-required chapter 13 features that are likely to be non-portable unless you have to. Indeed if you have to, then Sam's approach above is of course reasonable. But in this case, there is no need to use the rep clause, and good programming practice is to avoid non-essential rep clauses. For example, adding a confirming rep clause for an enumeration type is an example of a totally unnecessary nonsense rep clause when using an Ada 95 clause, but is at least not non-portable, since all compilers supporting Annex C must allow this clause (even if they may well generate inefficient code as a result). But the RM is quite explicit in suggesting that compilers need not support enum rep clauses for derived types of Boolean. Since such permissions are not put in their for idle amusement, you can assume that there will indeed be compilers that take advantage of this, e.g. to compile better code. Yes, you can include this rep clause and use it as a filter for acceptable compilers, but that is a bad choice, since you may be excluding a compiler just because it does not provide a feature that you should not be using anyway. On the other hand, it is quite clear from the RM that the intention is that a one-bit Boolean have representation 0,1 and it is quite impossible to imagine that any compiler would not provide this. Yes, I appreciate Sam may have been burned before, because you have to definitely know quite a bit to know what you can and cannot count on, but we are not discussing a general principle here, but rather one very specific example. I completely agree with Sam's general position here, I completely disagree that the application of this general position is appropriate to this particular case. The pragmatic case, as opposed to the formal RM case is equally strong in favoring approach 1, since in fact ALL Ada compilers DO of course use 0/1 as the default representation for 1-bit boolean (if you know a little about architecture, you will know that the only reason for allowing flexibility in boolean representation is to allow all 0 bits for False, and all 1 bits for True, and no other non-standard choice makes sense). On the other hand, it is definitely the case that using the rep clause may make your program needlessly non-portable. If portability is not an issue, that's OK, but it is remarkable how often non-portable code has to get ported :-) Similarly, it is quite likely that if a compiler *does* support a rep clause for derived booleans, that it will introduce significant inefficiency in the generated code. Sometimes one can tolerate inefficient code if you have no choice, but here you do have a choice. Once again, Sam's general point of view is right here, but knowing how to apply that position constructively and helpfully is indeed not easy. Here at Ada Core Technologies, we find that a significant part of our support consists of helping people use rep clauses in the most efficient way, and to understand how their code is or is not portable. Coding by superstition, rather than careful reasoning on a case by case basis is almost always risky, and can definitely lead to an incorrect choice. In particular, it is amazing how common it is, as in this case, for an attempt at writing portable code that exactly specifies what you mean, to be exactly counter-productive and end up making the code less portable! Robert Dewar Ada Core Technologies -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Samuel T. Harris @ 1998-09-24 0:00 ` matthew_snyder 1998-09-24 0:00 ` dennison ` (3 more replies) 1 sibling, 4 replies; 29+ messages in thread From: matthew_snyder @ 1998-09-24 0:00 UTC (permalink / raw) The reason for my original question is that I'm trying to decide the best (most portable) way to convert an UNSIGNED_8 to a record type which provides access to the individual bits. The record could either consist of booleans, or it could consist of my own bit type (is there a predefined BIT type that I'm overlooking?). Right now my record consists of booleans and I'm performing an unchecked conversion from UNSIGNED_8 to the record type. The option of doing a "for RECORD'ADDRESS use SOME_ADDRESS" is not available in this situation. Is any use of UNCHECKED_CONVERSION considered "junky coding"? I certainly would not want to have to do a 'POS on every bit to assure portability. What's the best way to do this? In article <6udriu$hfi$1@nnrp1.dejanews.com>, dewarr@my-dejanews.com wrote: > In article <6udkcj$87j$1@nnrp1.dejanews.com>, > matthew_snyder@my-dejanews.com wrote: > > Is it safe to make the assumption that a boolean value of FALSE will always > > be represented as a 0 and a value of TRUE will always be represented as a 1? > > Will an unchecked conversion from a boolean to an integer always yield the > > same results with different compilers? > > Whether true or false, this is junky coding, just use > Boolean'Pos (val) to get 0 or 1 in a for sure portable > manner. Remember that to use an unchecked conversion for > Boolean, you would have to use a 1-bit integer, anything > else most definitely gives an implementation defined result. > > -----== Posted via Deja News, The Leader in Internet Discussion ==----- > http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum > -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` matthew_snyder @ 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` Tom Moran ` (2 subsequent siblings) 3 siblings, 0 replies; 29+ messages in thread From: dennison @ 1998-09-24 0:00 UTC (permalink / raw) In article <6ue3uh$qjo$1@nnrp1.dejanews.com>, matthew_snyder@my-dejanews.com wrote: > The reason for my original question is that I'm trying to decide the best > (most portable) way to convert an UNSIGNED_8 to a record type which provides > access to the individual bits. The record could either consist of booleans, > or it could consist of my own bit type (is there a predefined BIT type that There are at least 12 better ways to do this! (Okay, maybe only 4 or so). Try looking into modular types or record types of boolean with a representation specification, or my personal favorite: arrays of booleans. Hint: bitwise "and" and "or" are predefined on arrays of booleans. "Let go of your C, Luke... *Feel* the Ada." -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` matthew_snyder 1998-09-24 0:00 ` dennison @ 1998-09-24 0:00 ` Tom Moran 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Robert I. Eachus 3 siblings, 1 reply; 29+ messages in thread From: Tom Moran @ 1998-09-24 0:00 UTC (permalink / raw) >UNSIGNED_8 to a record type which provides >access to the individual bits. Would "mod 256" do the job? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` Tom Moran @ 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Tom Moran 0 siblings, 1 reply; 29+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <360ab55c.12573963@SantaClara01.news.InterNex.Net>, tmoran@bix.com (Tom Moran) wrote: > >UNSIGNED_8 to a record type which provides > >access to the individual bits. > Would "mod 256" do the job? This is an odd question: UNSIGNED_8 *is* of course mod 256. I think you missed the point of the question, which is to convert something of type mod 256 to individual bits. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-25 0:00 ` dewarr @ 1998-09-25 0:00 ` Tom Moran 0 siblings, 0 replies; 29+ messages in thread From: Tom Moran @ 1998-09-25 0:00 UTC (permalink / raw) >This is an odd question: UNSIGNED_8 *is* of course mod 256. It appeared to me that the original questioner might be thinking UNSIGNED_8 was merely a range 0 .. 255, and not thinking in terms of its being a modular type, with OR and AND operations. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` matthew_snyder 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` Tom Moran @ 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Robert I. Eachus 3 siblings, 0 replies; 29+ messages in thread From: dewarr @ 1998-09-25 0:00 UTC (permalink / raw) In article <6ue3uh$qjo$1@nnrp1.dejanews.com>, matthew_snyder@my-dejanews.com wrote: > The reason for my original question is that I'm trying to decide the best > (most portable) way to convert an UNSIGNED_8 to a record type which provides > access to the individual bits. ALWAYS ask what you really have in mind, don't abstract it to something you think is similar. An unchecked conversion of an unsigned_8 type to a packed record with 8 boolean fields most certainly is perfectly reasonable, and has nothing to do with converting a stand alone boolean to an integer as implied by your original question. Note however that it will likely be implementation dependent (e.g. endian dependent) which order the bits come out in in the resulting packed record. There is no advantage in using your own type instead of Boolean, you definitely know that when a Boolean is forced to be represented in 1 bit, then 0 is false and 1 is true. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Boolean Representation 1998-09-24 0:00 ` matthew_snyder ` (2 preceding siblings ...) 1998-09-25 0:00 ` dewarr @ 1998-09-25 0:00 ` Robert I. Eachus 3 siblings, 0 replies; 29+ messages in thread From: Robert I. Eachus @ 1998-09-25 0:00 UTC (permalink / raw) In article <6ue3uh$qjo$1@nnrp1.dejanews.com> matthew_snyder@my-dejanews.com writes: > The reason for my original question is that I'm trying to decide > the best (most portable) way to convert an UNSIGNED_8 to a record > type which provides access to the individual bits. The record > could either consist of booleans, or it could consist of my own > bit type (is there a predefined BIT type that I'm overlooking?). > Right now my record consists of booleans and I'm performing an > unchecked conversion from UNSIGNED_8 to the record type. The > option of doing a "for RECORD'ADDRESS use SOME_ADDRESS" is not > available in this situation. Is any use of UNCHECKED_CONVERSION > considered "junky coding"? I certainly would not want to have to > do a 'POS on every bit to assure portability. What's the best way > to do this? Hmmm, do you really need the record type, or is access to the bits enough? with Interfaces; package Bit_Manipulation is subtype Index is Integer range 1..8; function Get(X: Interfaces.Unsigned_8; Bit: Integer) return Boolean; procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer); procedure Unset(X: in out Interfaces.Unsigned_8; Bit: in Integer); procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer; Value: in Boolean); pragma Inline(Get, Set, Unset); end Bit_Manipulation; package body Bit_Manipulation is use Interfaces; Mask: constant array(Index) of Interfaces.Unsigned_8 := (1,2,4,8,16,32,64,128); function Get(X: Interfaces.Unsigned_8; Bit: Integer) return Boolean is begin return (X and Mask(Bit)) /= 0; end Get; procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer) is begin X := X or Mask(Bit); end Set; procedure Unset(X: in out Interfaces.Unsigned_8; Bit: in Integer) is begin X := X and not Mask(Bit); end Unset; procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer; Value: in Boolean) is begin if Value then Set(X, Bit); else Unset(X, Bit); end if; end Set; end Bit_Manipulation; I haven't checked compilers to see if the resulting code is what you would expect for these operations, but it should come pretty close as long as Bit is static. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~1998-10-02 0:00 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-09-24 0:00 Boolean Representation matthew_snyder 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` Keith Thompson 1998-09-25 0:00 ` dennison 1998-09-25 0:00 ` Keith Thompson 1998-09-26 0:00 ` Tucker Taft 1998-09-26 0:00 ` Keith Thompson 1998-09-27 0:00 ` dewarr 1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr 1998-09-27 0:00 ` Keith Thompson 1998-09-28 0:00 ` dewarr 1998-09-28 0:00 ` Lieven Marchand 1998-09-28 0:00 ` Keith Thompson 1998-09-28 0:00 ` dewarr 1998-09-30 0:00 ` Keith Thompson 1998-10-02 0:00 ` Robert I. Eachus 1998-09-27 0:00 ` Boolean Representation dewarr 1998-09-24 0:00 ` dewarr 1998-09-24 0:00 ` Samuel T. Harris 1998-09-25 0:00 ` dewarr 1998-09-27 0:00 ` Samuel T. Harris 1998-09-28 0:00 ` dewar 1998-09-24 0:00 ` matthew_snyder 1998-09-24 0:00 ` dennison 1998-09-24 0:00 ` Tom Moran 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Tom Moran 1998-09-25 0:00 ` dewarr 1998-09-25 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox