From thomas.braun at byte-physics.de  Thu Sep  4 15:30:30 2025
From: thomas.braun at byte-physics.de (Thomas Braun)
Date: Thu, 04 Sep 2025 17:30:30 +0200
Subject: [omniORB] Sequences of strings
Message-ID: <f9c15ce259e6cca6387b9ffd296f22f392e155fa.camel@byte-physics.de>

Hi there,

I've again found some code in tango which does something I don't
understand.

Basically it boils down to having a definition like

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.

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

const char *wildcard = (*argin)[0];
if(wildcard == nullptr)
{
...
}

but I don't understand how the element of the string sequence can be a
nullptr?

If I really try hard to pass in a nullptr as element I get

omniORB: (0) 2025-09-04 16:39:14.621026: Application check failed. This
indicates a bug in the application
 using omniORB.  See the comment in the source code for more info.
 file: ../../../../include/omniORB4/cdrStream.h
 line: 454
 info: s

which for me strongly hints in the direction that the contained
elements in a sequence of strings are never a nullptr.

In case this is true, is that an omniORB speciality or mandated by the
CORBA standard?

Thanks,
Thomas






From duncan at grisby.org  Thu Sep  4 16:35:51 2025
From: duncan at grisby.org (Duncan Grisby)
Date: Thu, 04 Sep 2025 17:35:51 +0100
Subject: [omniORB] Sequences of strings
In-Reply-To: <f9c15ce259e6cca6387b9ffd296f22f392e155fa.camel@byte-physics.de>
References: <f9c15ce259e6cca6387b9ffd296f22f392e155fa.camel@byte-physics.de>
Message-ID: <89419aa635debfa6f6f49ebf1cb7cc04c8a6f5df.camel@grisby.org>

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>


From thomas.braun at byte-physics.de  Thu Sep  4 18:45:26 2025
From: thomas.braun at byte-physics.de (Thomas Braun)
Date: Thu, 04 Sep 2025 20:45:26 +0200
Subject: [omniORB] Sequences of strings
In-Reply-To: <89419aa635debfa6f6f49ebf1cb7cc04c8a6f5df.camel@grisby.org>
References: <f9c15ce259e6cca6387b9ffd296f22f392e155fa.camel@byte-physics.de>
 <89419aa635debfa6f6f49ebf1cb7cc04c8a6f5df.camel@grisby.org>
Message-ID: <047c23944da162bc4fa39fc01865751904bf61df.camel@byte-physics.de>

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