Missing return statement in ScoreboardGenericPkg

[Paebbels]

When compiling Scoreboard with Riviera-PRO, I get this warning:

COMP96 Compile Package Body "ScoreboardGenericPkg"
COMP96 WARNING COMP96_0048: "This function may complete without return statement." ".../lib/OSVVM/ScoreboardGenericPkg.vhd" 1525 5

[JimLewis]

Just noticing this now? It has been there since support for tagged scoreboards were added. Which I think from an OSVVM perspective, happened prior to being released as part of OSVVM.

In the current version, Riviera-PRO is reporting two:
ACOM: Warning: COMP96_0048: C:/SynthWorks/Dev/_osvvm/OsvvmLibraries/osvvm/ScoreboardGenericPkg.vhd : (1316, 5): This function may complete without return statement.
ACOM: Warning: COMP96_0048: C:/SynthWorks/Dev/_osvvm/OsvvmLibraries/osvvm/ScoreboardGenericPkg.vhd : (1746, 5): This function may complete without return statement.

Line 1316 is inside the function:
impure function LocalPeek (Index : integer ; Tag : string) return ListPointerType is
Line 1746 is inside the function:
impure function Find ( . . . ) return integer is

In both, they are doing an iterative descent of the list looking for a matching tag.
The both have code of the form:

loop 
    if Found the end of the list:      
        return   NOT FOUND
    elsif Found Tag:
        return   FOUND THING
    else                                        
       descend the list, loop and continue the search
    end if ; 
end loop

Provided the list is not infinite or circular (both of which would be a bug),
one of the "return" conditions will eventually be hit. Otherwise, if
there were a bug, the function would be in a "software infinite loop"
and never return.

I could program around this FALSE positive "warning", but should I?
It would require an extra variable. And it would not make the code
more robust (ie: a bug would still result in a software infinite loop).

I will be honest, I have been working hard to work around tool bugs
that cause compile failures. This one has not been on my radar.

This one is kind of like the warnings reported for NULL arrays.

Maybe we need a forum in OSVVM.org or here that has a list of normal
messages with an explanation like above.

[Paebbels]

We needed to do a deep analysis of compile logs, so I went through everything. While doing so, I found this. If I remember I never saw such a warning poping up before, that's why I reported. But if you say it exists since a while and a solution would be to much of an investment, it's OK for me.

Maybe a list of expected tool warnings (justification report) would be good and could support user in safety critical environments when using OSVVM.

[JimLewis]

It is easy to address. Do we fix code for a tool that produces a FALSE positive on a check?
Do we stop using null ranges on arrays - the language allows it, but tools yack about it?

OTOH, if there are safety critical coding styles, and this code violates it, then I would
be happy to update it.

New coding style would be:

loop 
    if Found the end of the list:      
        Result := NOT FOUND
        exit ; 
    elsif Found Tag:
        Result := FOUND THING
        exit ; 
    else                                        
       descend the list, loop and continue the search
    end if ; 
end loop
return Result ; 

This code is not any safer than the other code. In fact, the irony is that the compiler could
optimize away the Result variable and produce the same optimized implementation.

[JimLewis]

@Paebbels Should I make the proposed change above?