[omniORB] String handling problem with VC7.1

[bjorn rohde jensen]

Carlos wrote:
> El jue, 22-03-2007 a las 19:05 +0100, bjorn rohde jensen escribió:
> 
>>Matej Kenda wrote:
>>
>>>Hi Severin,
>>>
>>>2007/3/22, Ecker Severin <Severin.Ecker at arcs.ac.at>:
>>>
>>>
>>>>static inline void free(char* s) {
>>>>  if (s && s != empty_string) delete[] s;
>>>>}
>>>>
>>>>For some reason the condition hold true and attempts are made to delete
>>>>an invalid string resource. As you can see above I just want to assign a
>>>>string to a completely new and fresh corba object (the id string) which
>>>>does have the value 'empty_string' at the time of my assignment
>>>>statement.
>>>
>>>
>>>I suspect that you are using non-debug and debug versions of MS C
>>>runtime library: one is used by the omniORB and the other is used by
>>>your application.
>>>
>>>The string gets allocated in one heap and wants to get deallocated in
>>>another.
>>>
>>>HTH,
>>>
>>>Matej
>>
>>I would say,the problem is, when you assign the constant pointer to
>>var.id, var assumes ownership of the memory pointed to, and it will
>>attempt to free it, when the variable releases ownership of it.
>>CosNaming::Name behaves like _var types in that respect, and your
>>runtime is quite right to complain about freeing string constants.
>>
> 
> 
> I don't agree with you, Bjorn, because
> 
> CosNaming::Name var;
> var.length(1);
> var[0].id = (const char*)"test";
> 
> is correct, what you say is correct if the code is
> 
> var[0].id = "test";
> 
> in this case "test" is char* type, so var[0].id assumes the ownership,
> but whith the cast (const char*) var[0].id creates a copy and assumes
> the ownership of the copy.
> 
> Really I don't know which can be the problem because that code is
> correct, I use it a lot of times in linux (whith a lot of g++ versions)
> and I never use windows platforms because I think they are problematic
> platforms ;)
> 
> 
> Cheers.
> 
> Carlos.
> 
> 
>>_______________________________________________
>>omniORB-list mailing list
>>omniORB-list at omniorb-support.com
>>http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>>
> 
> 
> 

 Ah yes, you are right, the const cast does force a deep copy, so matej
is probably right, you are mixing runtime and debug libs. Never used
casting to force the deep copies, i like string_dup("test") better.

 Omniorb libs are build in both debug and release versions on windows. I
think, the naming convention is that if bla.dll or bla_rt.dll is the
release version, then blad.dll or bla_rtd.dll is the debug version.
Windows libs are indeed weird.

 Your windows compiler thingie should have some tab with a text field
for extra libraries during linking, try checking the omni libs there
against the omni docu.