Issue 588: limited-length strings (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section? Resolution: Incorporate change in 2.3a and close issue Revised Text: ° A string type, which consists of a variable-length array of characters Actions taken: May 29, 1997: received issue February 22, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA006EEAC85A3731 Date: Thu, 29 May 1997 11:43:49 PDT Subject: limited-length strings To: rabin@osf.org cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org In making my minor edits, I noticed that limited-length strings are missing from the enumeration in section 1.2.4. It's not obvious to me whether they were intended to go in the "Basic types" (along with unlimited strings) or the "Constructed types" section (they *are* constructed, after all). Return-Path: Sender: jon@floorboard.com Date: Tue, 01 Sep 1998 20:22:12 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Proposals for 68, 588, 911, 1753 [All of the textual locations are relative to the new CORBA 2.3 draft documents in the ptc/98-08-?? series.] --------------------------------------------------------------------------------- Issue 68: Missing info about the semantics of ORB_init and OA_init Proposal: Add the following text to the next to last paragraph of section 4.6: Before ORB_init returns, it will remove all strings that match the -ORB pattern described above from the argv parameter. --------------------------------------------------------------------------------- Issue 588: limited-length strings Proposal: Modify the bullets in 1.2.4.1 for strings and wide strings to read: 0 A string type, which consists of a variable-length array of characters (a null character is one whose character code is 0); the length of the string is a non-negative integer, and is available at run-time. The length may have a maximum bound defined. 0 Wide character strings, which consist of a variable-length array of (fixed width) wide characters; the length of the wide string is a non-negative integer, and is available at run-time. The length may have a maximum bound defined. --------------------------------------------------------------------------------- Issue 991: Operations to add to CORBA::ORB pseudo-objec Proposal: [Note I have expanded the SerializedEncoding IDL type to include version information, since we now have 3 versions of CDR!] The following operations should be added to the CORBA::ORB pseudo-object: module CORBA { interface ORB { ... typedef sequence SerializedData; typedef unsigned long SerializedFormat; const SerializedFormat ENCODING_CDR = 0; struct SerializedEncoding { SerializedFormat format; octet major_version; octet minor_version; }; SerializedData serialize(in Any data, in SerializedEncoding how); Any unserialize(in SerializedData data, in SerializedEncoding how); SerializedData serialize_value(in Any data, in SerializedEncoding how); Any unserialize_value(in SerializedData data, in SerializedEncoding how, in TypeCode tc); ... }; }; These operations provide a standard mechanism for serializing and unserializing the data in an any, along with hooks to support new encoding formats as they are needed. The type SerializedEncoding indicates the encoding mechanism to use to serialize and unserialize the data. The format field specifies what encoding rules to use when serializing the data, and the major_version and minor_version indicate what version of the encoding rules to use. The serialize and unserialize encode the TypeCode along with the value so that the serialized data is self contained. The serialize_value and unserialize_value version encodes the value without the TypeCode to save space, but a TypeCode must be supplied to unserialize the data. Since the serialized data may contain no indication of machine dependent issues such as byte order, the serialized data can only be guaranteed to correctly be unserialized on the same ORB. The IDL any type should be used to exchange information between ORBs. Data encoded using the ENCODING_CDR format will be encoded using CDR encapsulation format. --------------------------------------------------------------------------------- Issue 1753: Size of IDL char Proposal: Close without change. I've been thinking about this one, and I think the text is correct. The char type is an 8-bit quantity with an allowed range of 0-255. The storage size of a char is a language-binding issue, not a core issue. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org