[omniORB] Sequences of strings

[Duncan Grisby]

On Thu, 2025-09-04 at 17:30 +0200, Thomas Braun via omniORB-list wrote:


[...]
> typedef sequence<string> DevVarStringArray;
> 
> in the IDL file.
> 
> And then a C++ function on the server side which has the following
> signature:
> 
> void DataBase::dostuff(const Tango::DevVarStringArray *argin)
> 
> Now I already found out from reading documentation (omniORB, Advanced
> CORBA Programming with C++ and helpful colleagues) that argin can
> never be a nullptr.

Correct. The CORBA standard (not just the C++ mapping, the whole
standard) does not allow any datatype to be null, except for
valuetypes, which explicitly can be null.

(Object references can be nil, which in some language mappings is
mapped to the language's null / None value, but in C++ is permitted to
be a distinguished object that is not nullptr. In omniORB, a nil object
reference is an object, not nulltr.)


> But what about the elements of argin? The code does something like

They are also not allowed to be null, according to the core standard.

The C++ mapping strangely does not say that strings (mapped to char*)
cannot be nullptr, but it is clearly the case because there is no
concept of a null string in the core standard.


[...]
> const char *wildcard = (*argin)[0];
> if(wildcard == nullptr)
> {
> ...
> }
> 
> but I don't understand how the element of the string sequence can be
> a nullptr?

In a remote CORBA call, a string in the sequence will never be nullptr.
The sender cannot send one (as you see), and because there is no
marshalled representation for a null string, the receiver cannot
possibly receive one.

However, if the sender and receiver are in the same process, omniORB
short-cuts the call so the data is not marshalled at all — if a
sequence<string> is passed as a parameter to an operation, the function
implementation gets a direct pointer to the caller's sequence object.
You could therefore manage to pass a nullptr through a sequence without
omniORB stopping you, but you would be breaking the rules.

Maybe the code you are looking at is trying to detect that case?

Duncan.


-- 
Duncan Grisby <duncan at grisby.org>