[omniORB] Add [[noreturn]] attribute to functions throwing exceptions

[Duncan Grisby]

On Thu, 2021-02-25 at 16:39 +0100, Michał Liszcz via omniORB-list
wrote:
[...]
> We are seeing some false positives coming from omniORB headers
> (mostly from seqTemplatedecls.h and stringtypes.h). The analyzer
> takes impossible execution path because it does not have access to
> definitions of throwing functions like
> _CORBA_new_operator_return_null. For instance we see this warning:
> 
> /usr/include/omniORB4/stringtypes.h:730:13: warning: Array access
> (from variable 'newdata') results in a null pointer dereference
> [core.NullDereference]
>         newdata[i] = pd_data[i];

[...]
> What I propose to do is to explicitly indicate that these functions
> are not going to return but will throw an exception by putting
> [[noreturn]] attribute in definitions in CORBA_basetypes.h:
> 
> [[noreturn]] extern void _CORBA_new_operator_return_null();
[...]

Yes, that seems like a good thing to do.

omniORB still targets old compilers (and modern ones running backward
compatibility modes) that do not support C++11, so it will have to be
done with a pre-processor definition rather than directly like that.

> Another thing worth considering is to replace comments like below one
> with assertions (assert(pd_len <= newmax)) that would enforce these
> invariants and would also provide some valuable information for
> static analysis tools.
>     // Invariant:  pd_len <= newmax

It can't directly do that, because omniORB is used on some platforms
where we don't want to use assert. It could use OMNIORB_ASSERT, but
that is likely to provoke the same sort of confusion in static analysis
tools.

> I can work on a patch if above proposals can be accepted, but I'd
> need some guidance.

Feel free to email a patch that works these ways. The patch should be
against the 4_3 branch.

Duncan.

-- 
 -- Duncan Grisby --
  -- duncan at grisby.org --
   -- http://www.grisby.org --