Issue 107: Sequence release flag implementation (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Section 14.11 of the C mapping introduces a release flag hidden inside the C struct; however, that struct is completely specified and leaves no bit for that flag. How does this work? Resolution: Close with no change Revised Text: Actions taken: September 11, 1996: Received issue December 12, 1996: moved from cxx_revision to c-rev-wg October 5, 2000: closed issue Discussion: The section introduces a release flag but it does not put the flag inside the C struct. The section states "the location of this release flag is implementation dependent." Since the flag is only accessible via defined interfaces it location is not significant. End of Annotations:===== From geoff Wed Sep 11 13:30:12 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05384; Wed, 11 Sep 1996 13:30:12 -0400 Date: Wed, 11 Sep 1996 13:30:12 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111730.AA05384@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: C mapping: sequence release flag implementation? X-Omg-Issue: 107 Date: Mon, 9 Sep 1996 17:12:51 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: C mapping: sequence release flag implementation? Cc: orbos@omg.org In section 14.11, ``Mapping for Sequence Types'', we are introduced to a mysterious release flag hidden inside the C struct representing a sequence type, somehow. Unfortunately, that C struct is completely specified (in contrast to the CORBA_Environment struct, for example, which is partially opaque), and contains no bit reserved for the release flag. In addition, the default value for the release flag must be FALSE. Since these sequence structs may be either stack or heap allocated, the only reasonable way to preserve most of these required semantics is to keep a hash table or list of sequence values for which the release flag is TRUE. Even this has the defect of ``flipping'' the release flag from TRUE to FALSE when the sequence struct is assigned to a variable of the appropriate type. How is this supposed to work correctly? Bill >From mail Wed Oct 9 14:43 EDT 1996 Sender: Bill Janssen From: Bill Janssen To: c-rev-wg@omg.org Subject: suggested resolution for issue 107 (sequence release flag implementation?) Date: Wed, 9 Oct 1996 11:40:22 PDT Content-Length: 1474 A number of issues are about the need to associate meta-data or implementation data with data structures that are fully described in the mapping spec. I suggest that the best way to address these issues is to make all documented structures `partially opaque', in particular the `sequence' and `any' structs, and add required operators (macros or functions) to properly initialized a stack-allocated value of this type. For example, the mapping for typedef sequence vec10; would become typedef struct { /* Pseudo-C */ CORBA_unsigned_long _maximum; CORBA_unsigned_long _length; CORBA_long *_buffer; [ ... possible other fields ... ] } vec10; and the struct for `any' would change to typedef struct CORBA_any { /* Pseudo-C */ CORBA_TypeCode _type; void *_value; [ ... possible other fields ... ] } CORBA_any; This would require adding some required initialization procedures/macros, to properly initialize stack-allocated versions of these values: #define CORBA_sequence_initialize(s_ptr) \ { (s_ptr)->_maximum = 0; \ (s_ptr)->_length = 0; \ (s_ptr)->_buffer = 0; \ [ ... possible other initializations ... ] \ } #define CORBA_any_initialize(a_ptr) \ { (a_ptr)->_type = 0; \ (a_ptr)->_value = 0; \ [ ... possible other initializations ... ] \ } Note that this approach also incorporates Sun's suggested feature change. Bill >From mail Wed Oct 9 14:43 EDT 1996 Sender: Bill Janssen From: Bill Janssen To: c-rev-wg@omg.org Subject: suggested resolution for issue 107 (sequence release flag implementation?) Date: Wed, 9 Oct 1996 11:40:22 PDT Content-Length: 1474 A number of issues are about the need to associate meta-data or implementation data with data structures that are fully described in the mapping spec. I suggest that the best way to address these issues is to make all documented structures `partially opaque', in particular the `sequence' and `any' structs, and add required operators (macros or functions) to properly initialized a stack-allocated value of this type. For example, the mapping for typedef sequence vec10; would become typedef struct { /* Pseudo-C */ CORBA_unsigned_long _maximum; CORBA_unsigned_long _length; CORBA_long *_buffer; [ ... possible other fields ... ] } vec10; and the struct for `any' would change to typedef struct CORBA_any { /* Pseudo-C */ CORBA_TypeCode _type; void *_value; [ ... possible other fields ... ] } CORBA_any; This would require adding some required initialization procedures/macros, to properly initialize stack-allocated versions of these values: #define CORBA_sequence_initialize(s_ptr) \ { (s_ptr)->_maximum = 0; \ (s_ptr)->_length = 0; \ (s_ptr)->_buffer = 0; \ [ ... possible other initializations ... ] \ } #define CORBA_any_initialize(a_ptr) \ { (a_ptr)->_type = 0; \ (a_ptr)->_value = 0; \ [ ... possible other initializations ... ] \ } Note that this approach also incorporates Sun's suggested feature change. Bill Date: Mon, 13 Mar 2000 18:11:24 -0500 From: "Barker, Thomas" Subject: Issues to be discused and voted by 3/24/2000(COB) To: "'C-RFT'" Message-id: <99AA2270B1E6D111BCE10000F805F17F043EB1FD@emss35m02.owg.fs.lmco.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-transfer-encoding: 7BIT Content-Type: text/plain; charset=iso-8859-1 X-UIDL: K,Ie9SN0!!?]7!!*@,!! I want to start making some progress on the C RTF (I aplologize for not getting to it earlier, but it been a bad fall and winter). I think that many of the issues can be dealt with quickly so I propose to try to kill about 10 per week for the next couple of months. This batch seemed typical. I just took the first 10 from the list at http://www.omg.org/issues/c_mapping-rtf.html. I'd think the requirement for a vote by 3/24 seems reasonable, but if I discusion between now and 3/17 indicates that any particular issue(s) are not agreeable to everyone I will pull that issue(s) from the list to be voted in this batch. I have gone through the issues, copied the name and summary sentence into this note, then proposed a resolution for each. Tom Issue 107: Sequence release flag implementation Summary: Section 14.11 of the C mapping introduces a release flag hidden inside the C struct; however, that struct is completely specified and leaves no bit for that flag. How does this work? Discussion - The section introduces a release flag but it does not put the flg inside the C struct. In fact ithe section states "the location of this release flag is implementation dependent." Since the flag is only accessible via defined interfaces it location is not significant. I suggest we close this with no change.