Issue 594: Boolean type left undefined by C++ mapping (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: CORBA::Boolean can be mapped to totally non-sensical things such as structs, class, type double, type long etc. There are no guarantees about size of underlying type given to implementor Resolution: resolved, close issue Revised Text: Actions taken: June 18, 1997: received issue February 19, 1999: closed issue, resolved Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Wed, 18 Jun 1997 10:53:34 +1000 (EST) From: Michi Henning To: issues@omg.org Subject: Boolean type left undefined by C++ mapping The C++ mapping makes no apparent statement as to what range of C++ types are legal as a representation of CORBA::Boolean (below is an article I posted to comp.object.corba with the details). The problem I see is that CORBA::Boolean can be mapped to totally non-sensical things, such as a struct, class, type double, type long, etc. The problem introduced by this is that no guarantees about the size of the underlying type is given to the implementor. I think it would be nice to tighten the spec such that better guarantees about the boolean C++ type and sizeof(CORBA::Boolean) can be given. Unfortunately, that would rule out C++ bool (because ANSI-C++ does not give guarantees about sizeof(bool)). Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html On Wed, 18 Jun 1997, Evan Ireland wrote: > Does anyone know of any ORB for which > > sizeof(CORBA::Boolean) (C++ mapping) > > or > > sizeof(CORBA_Boolean) (C mapping) > > is not equal to 1? Is it legal for it to be anything other than 1? It depends... ;-) For starters, IDL does not make any guarantee at all about the size of a boolean. This means the size is up to each language mapping. A language mapping can make it a one bit value, a one byte value, or a one kB value and still be compliant with IDL. If you are using the C mapping, boolean is required to map to char. In C, by definition, sizeof(char) == 1 (even on machines where chars are represented by something other than an 8-bit byte). So, for the C mapping, sizeof(CORBA_Boolean) is guaranteed to be 1. For the C++ mapping, things are not so simple... The C++ mapping spec does not actually state to what target type boolean should be mapped. It says that IDL boolean maps to CORBA::Boolean, but then does not say anything about what native C++ type CORBA::Boolean should be mapped to. The C++ mapping says that CORBA::Boolean *can* map to the same C++ type as char or octet, which means that a mapping of CORBA::Boolean to char, signed char, or unsigned char is definitely legal. The spec also hints at the fact that a mapping to native C++ bool would be compliant (page 16-11): "Alternatively, for those C++ compilers that support the new bool type, the keywords true and false may be used." Although the above really only really says that whatever type is used for boolean, it must be possible to assign keywords true and false to it, which is not quite the same thing... >From my reading of the spec, mapping CORBA::Boolean to C++ double would actually be a compliant implementation (as long as you never put a value other than 0 or 1 (or true or false) into the boolean which is represented as a double). Regardless, what it all boils down to is this: In C, sizeof(CORBA_Boolean) == 1, guaranteed. In C++, sizeof(CORBA::Boolean) == 1 if your compiler has chosen to map boolean to a character type (which is highly likely). If you have a new C++ compiler supporting the bool type, and the mapping maps to C++ bool, then sizeof(CORBA::Boolean) can be anything. This is because ANSI-C++ does not make any requirements as to sizeof(bool). To me, the entire thing really smacks of a specification defect. I can live with *IDL* not making any size requirements for boolean. However, the C++ spec as it stands right now makes no requirements at all. In fact, according to my reading of the spec, I can implement a compliant C++ mapping right now that uses a class to store a boolean! As long as the necessary conversion operators are present, so I can assign 0 and 1 (or true and false), and test a boolean value in an integer expression context, the mapping will be compliant. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu..au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@sems.com Date: Wed, 18 Jun 1997 10:00:02 -0700 From: Jonathan Biggar Organization: Seagate Software NMSG To: Michi Henning Cc: issues@omg.org Subject: Re: Boolean type left undefined by C++ mapping References: Michi Henning wrote: > > The C++ mapping makes no apparent statement as to what range of C++ > types > are legal as a representation of CORBA::Boolean (below is an article > I posted > to comp.object.corba with the details). > > The problem I see is that CORBA::Boolean can be mapped to totally > non-sensical > things, such as a struct, class, type double, type long, etc. > The problem introduced by this is that no guarantees about the size > of > the underlying type is given to the implementor. > > I think it would be nice to tighten the spec such that better > guarantees > about the boolean C++ type and sizeof(CORBA::Boolean) can be given. > Unfortunately, that would rule out C++ bool (because ANSI-C++ does > not > give guarantees about sizeof(bool)). Actually, I see absolutely no reason for the C++ mapping to say anything about the size of CORBA::Boolean, particularly if it would rule out C++ bool. Why make things harder than they have to be? The only reason to want this would be to make some binary level guarantee of portability. This is certainly beyond the scope of the C++ mapping to legislate, since there are too many other C++ binary portability issues that CORBA cannot address, such as name mangling, virtual table layout, etc, not to mention the ones that the C++ spec has deliberately NOT addressed, such as whether interface operations are C++ virtual members, whether IDL inheritence maps to C++ inheritence, among others. Jon Biggar jon@sems.com Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Wed, 18 Jun 1997 10:53:34 +1000 (EST) From: Michi Henning To: issues@omg.org Subject: Boolean type left undefined by C++ mapping The C++ mapping makes no apparent statement as to what range of C++ types are legal as a representation of CORBA::Boolean (below is an article I posted to comp.object.corba with the details). The problem I see is that CORBA::Boolean can be mapped to totally non-sensical things, such as a struct, class, type double, type long, etc. The problem introduced by this is that no guarantees about the size of the underlying type is given to the implementor. I think it would be nice to tighten the spec such that better guarantees about the boolean C++ type and sizeof(CORBA::Boolean) can be given. Unfortunately, that would rule out C++ bool (because ANSI-C++ does not give guarantees about sizeof(bool)). Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html On Wed, 18 Jun 1997, Evan Ireland wrote: > Does anyone know of any ORB for which > > sizeof(CORBA::Boolean) (C++ mapping) > > or > > sizeof(CORBA_Boolean) (C mapping) > > is not equal to 1? Is it legal for it to be anything other than 1? It depends... ;-) For starters, IDL does not make any guarantee at all about the size of a boolean. This means the size is up to each language mapping. A language mapping can make it a one bit value, a one byte value, or a one kB value and still be compliant with IDL. If you are using the C mapping, boolean is required to map to char. In C, by definition, sizeof(char) == 1 (even on machines where chars are represented by something other than an 8-bit byte). So, for the C mapping, sizeof(CORBA_Boolean) is guaranteed to be 1. For the C++ mapping, things are not so simple... The C++ mapping spec does not actually state to what target type boolean should be mapped. It says that IDL boolean maps to CORBA::Boolean, but then does not say anything about what native C++ type CORBA::Boolean should be mapped to. The C++ mapping says that CORBA::Boolean *can* map to the same C++ type as char or octet, which means that a mapping of CORBA::Boolean to char, signed char, or unsigned char is definitely legal. The spec also hints at the fact that a mapping to native C++ bool would be compliant (page 16-11): "Alternatively, for those C++ compilers that support the new bool type, the keywords true and false may be used." Although the above really only really says that whatever type is used for boolean, it must be possible to assign keywords true and false to it, which is not quite the same thing... >From my reading of the spec, mapping CORBA::Boolean to C++ double would actually be a compliant implementation (as long as you never put a value other than 0 or 1 (or true or false) into the boolean which is represented as a double). Regardless, what it all boils down to is this: In C, sizeof(CORBA_Boolean) == 1, guaranteed. In C++, sizeof(CORBA::Boolean) == 1 if your compiler has chosen to map boolean to a character type (which is highly likely). If you have a new C++ compiler supporting the bool type, and the mapping maps to C++ bool, then sizeof(CORBA::Boolean) can be anything. This is because ANSI-C++ does not make any requirements as to sizeof(bool). To me, the entire thing really smacks of a specification defect. I can live with *IDL* not making any size requirements for boolean. However, the C++ spec as it stands right now makes no requirements at all. In fact, according to my reading of the spec, I can implement a compliant C++ mapping right now that uses a class to store a boolean! As long as the necessary conversion operators are present, so I can assign 0 and 1 (or true and false), and test a boolean value in an integer expression context, the mapping will be compliant. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu..au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html