[omniORB] Sequences of strings

[Thomas Braun]

Am Donnerstag, dem 04.09.2025 um 17:35 +0100 schrieb 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.)

Good!

> 
> > 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.
> 

Perfect!

> 
> [...]
> > 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.

Thanks, that is what I needed to be confirmed.

> 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?

It does not look like that. At least now this is a standalone server.

Thanks again for the thorough and quick answer,
Thomas