CORBA style was: [omniORB] CORBA::string_alloc(len) problem

[Bjorn Wennberg]

David Riddoch <djr@uk.research.att.com> writes:

> On 16 Jul 1999, Bjorn Wennberg wrote:
> 
> > Back to the example of accessing the elements of the String_var;
> > What is wrong with doing:
> > String_var SomeString = CORBA::string_alloc(100);
> 
> The above line is the problem.  The c++ spec says that this is equiv to
> 
> String_var SomeString;
> {
>   String_var _tmp(CORBA::string_alloc(100));
>   SomeString = _tmp;
> }
> 
> Thus we attempt to copy a string which is uninitialised.  In the case of
> omniORB it will have been initialised to the empty string -- but this just
> means we will end up with a buffer of length 1 instead of 101 as intended.
> Now most compilers optimise away _tmp and the assignment to give what 
> you'd expect, but a few (eg. on VAX) don't.

I'm just curious about this :-)

As far as I'm able to understand the behaviour of string_alloc - it returns
a character pointer not a new String_var class?

Thus the assignment would be correct without temporary copying the String_var:

1. String_var SomeString(CORBA::string_alloc(100));
2. String_var SomeString(new char[100]);
3. String_var SomeString = CORBA::string_alloc(1000);
Number 1 and 2 are equal and uses the ctor:
String_var::String_var(char *p) { _data = p; }
Number 3 might use either the ctor or the assignment operator, which are equal:
String_var::operator = (char *p) { if (_data) string_free(_data); _data = p; }

Then I can't see what is wrong with doing
String_var SomeString = string_alloc(100);
char *ptr = SomeString;
ptr[0] = 'f';
ptr[1] = 'o';
ptr[2] = 'o';
ptr[3] = 0;

Please correct me if I'm missing something here :-)

bjornw>