Issue 5466: conversion algorithm not specified (cxx_revision) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: C++ programmers will often want to use strings as object identifiers, the C++ mapping provides several conversion functions that convert strings to ObjectId and vice-versa:" The purpose is so the programmer can pick an arbitrary natural language string and use it as an ObjectId, not so that the programmer can generate a randomly unreadable string out of a binary ObjectId. [...] the C++ mapping provides several conversion functions that convert strings to ObjectId and viceversa: [...] If conversion of an ObjectId to a string would result in illegal characters in the string (such as a NUL), the first two functions throw the CORBA::BAD_PARAM exception. The conversion algorithm is not specified, and the ORB is free to choose whatever encoding it likes for its Object IDs. (Object IDs in stringified form need not be moved across address spaces (or, at least, not across ORB boundaries), so having a proprietary encoding is perfectly OK.) Resolution: Revised Text: Actions taken: July 19, 2002: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Reply-To: "Michi Henning" From: "Michi Henning" To: Subject: Re: ObjectId_to_string throws exception Date: Fri, 19 Jul 2002 08:14:01 +1000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 "Jonathan Biggar" wrote in message news:3D36F7DD.D775855D@floorboard.com... > > > > Hmmm... I seem to remember that, elsewhere, the spec says that > > string_to_ObjectId() may fail for SYSTEM_ID *if* the supplied ID > > isn't in the format that is used by the ORB. It would seem to follow > > that, if the supplied ID *is* in the format that is used by the ORB, > > string_to_ObjectId() must work? > > You are misremembering the part of the spec about calling > activate_object_with_id() on a POA with SYSTEM_ID. Yes, you are right. > It would have been better, in retrospect, if ObjectId_to_string() was > specified to hexify the ObjectId and vice versa for string_to_ObjectId, > but it wasn't. Instead, it is a direct transliteration of characters to > octets and vice versa. Actually, having just looked again, the spec doesn't say that anywhere either. Here is what it *does* say: [...] the C++ mapping provides several conversion functions that convert strings to ObjectId and viceversa: [...] If conversion of an ObjectId to a string would result in illegal characters in the string (such as a NUL), the first two functions throw the CORBA::BAD_PARAM exception. The conversion algorithm is not specified, and the ORB is free to choose whatever encoding it likes for its Object IDs. (Object IDs in stringified form need not be moved across address spaces (or, at least, not across ORB boundaries), so having a proprietary encoding is perfectly OK.) > > At any rate, if I go to an object with SYSTEM_ID, it surely > > would seem reasonable to expect ObjectId_to_string() (and > > vice versa) to work? > > It might, but that's not the way it works. Sorry, I disagree. For one, the spec is clearly broken because the conversion algorithm isn't specified. Given that, it makes little sense to talk about what should happen if it fails. Second, the idea of having valid object IDs that are not representable as valid stringified object IDs is preposterous -- it is completely self-defeating: first, we choose an octet sequence as the object ID so people are not restricted in the kind of key they can use, then we create ObjectId_to_string and vice-versa for the C++ mapping because octet sequences are awkward to manipulate, and then, to top it all off, we state that, actually, if there are binary charcters in the octet sequence, you can't use the helper functions anyway. That's really clever! :-( I've CC'd issues on this because that's clearly a defect. I would suggest to define the mapping as a literal copy of the octet sequence, with byte-stuffing to escape a NUL char as "\0" and encoding a literal backslash as "\\". Alternatively, universal character names could be used for both wide and narrow strings to map away from the zero character. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi Sender: jbiggar@Resonate.com Date: Thu, 18 Jul 2002 15:52:29 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Michi Henning CC: issues@omg.org Subject: Re: ObjectId_to_string throws exception Michi Henning wrote: > > > Hmmm... I seem to remember that, elsewhere, the spec says that > > > string_to_ObjectId() may fail for SYSTEM_ID *if* the supplied ID > > > isn't in the format that is used by the ORB. It would seem to follow > > > that, if the supplied ID *is* in the format that is used by the ORB, > > > string_to_ObjectId() must work? > > > > You are misremembering the part of the spec about calling > > activate_object_with_id() on a POA with SYSTEM_ID. > > Yes, you are right. > > > It would have been better, in retrospect, if ObjectId_to_string() was > > specified to hexify the ObjectId and vice versa for string_to_ObjectId, > > but it wasn't. Instead, it is a direct transliteration of characters to > > octets and vice versa. > > Actually, having just looked again, the spec doesn't say that > anywhere either. Here is what it *does* say: > > [...] the C++ mapping provides several conversion functions > that convert strings to ObjectId and viceversa: > [...] > If conversion of an ObjectId to a string would result in > illegal characters in the string (such as a NUL), the first two > functions throw the CORBA::BAD_PARAM exception. > > The conversion algorithm is not specified, and the ORB is free to > choose whatever encoding it likes for its Object IDs. (Object IDs > in stringified form need not be moved across address spaces (or, > at least, not across ORB boundaries), so having a proprietary > encoding is perfectly OK.) You missed the part right above that, which explains the purpose of the functions: "However, because C++ programmers will often want to use strings as object identifiers, the C++ mapping provides several conversion functions that convert strings to ObjectId and vice-versa:" The purpose is so the programmer can pick an arbitrary natural language string and use it as an ObjectId, not so that the programmer can generate a randomly unreadable string out of a binary ObjectId. BTW, in case it's unclear, this is an issue for the C++ mapping. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Reply-To: "Michi Henning" From: "Michi Henning" To: "Jonathan Biggar" Cc: Subject: Re: ObjectId_to_string throws exception Date: Fri, 19 Jul 2002 08:57:11 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > > The conversion algorithm is not specified, and the ORB is free to > > choose whatever encoding it likes for its Object IDs. (Object IDs > > in stringified form need not be moved across address spaces (or, > > at least, not across ORB boundaries), so having a proprietary > > encoding is perfectly OK.) > > You missed the part right above that, which explains the purpose of > > the > functions: > > "However, because C++ programmers will often want to use strings as > object identifiers, the C++ mapping provides several conversion > functions that convert strings to ObjectId and vice-versa:" Sure, those words are there. But they don't say *how* an object ID is to be represented as a string -- it just says that there are conversion functions, and states nothing about the contents of the string. > The purpose is so the programmer can pick an arbitrary natural language > string and use it as an ObjectId, not so that the programmer can > generate a randomly unreadable string out of a binary ObjectId. Right. But to have cases in which conversion of a legal object ID fails is obtuse, to say the least. After all, there are several perfectly servicable conversions that can be used; instead, the spec refuses to use any of them and "fixes" things by adding an unnecessary run-time exception to something that needn't ever fail in the first place. > BTW, in case it's unclear, this is an issue for the C++ mapping. Yep! Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi