Warning Search Language

• Warning-Specific Grammar
• Examples
• SQL Terms

Warning-Specific Grammar

The warning search language grammar is based on the standard CodeSonar search grammar, with several extensions:

• In addition to the T types provided in the standard search grammar, there is a new T set-operator T term.
  • Important Note: Any search that includes one or more T set-operator T terms will return a result set containing at most one instance per warning group. This is the case even if Visible Warnings is set to all.
  • Precedence rules are as follows.

    Within T:

     () > unary > binary > set-operator
    

    Within set-operator:

     INTERSECT > UNION = DIFFERENCE
              
    

    (Within binary, precedence is still & > |)

• In addition to the condition types provided in the standard search grammar, there are warning-id-range and hash-value conditions.
• There are domain-specific field-name values.
• none (case insensitive) is not treated as an ordinary word. Instead, it matches all of the following.
  • literal string none (case insensitive)
  • fields whose value is the empty string
  • empty fields (that is, fields that don't contain any value at all, not even a default value)
  Plain text search in the warning search language covers a large number of fields, including some that many users choose to leave empty, such as Analysis Description (adesc). Consequently, performing a plain text search for none (or "none", which CodeSonar will normalize to none) may match many warnings that do not contain literal string none.To avoid this issue, use one or more field-condition, ilike-condition, or imatch-condition terms to restrict the search to the precise field or fields you are interested in.

Literal strings are displayed in pink text.

T : quoted-string
  | field-condition
  | ilike-condition
  | imatch-condition
  | ( T )
  | unary T
  | T binary T
  | T set-operator T
  | T T
  | word
  | none
        
field-name : adesc 
           | aid
           | analysis
           | categories
           | class
           | cluster
           | clustered
           | detected
           | file
           | finding
           | fingerprint
           | firstdetected
           | id
           | iid
           | language
           | line
           | line_content
           | line_content_xml
           | listing
           | listing_xml
           | modified
           | new_warning
           | notes
           | owner
           | path
           | priority
           | project
           | pdesc
           | procedure
           | ptree_path 
           | rank
           | score
           | significance
           | similar
           | sql
           | state
                   
condition : warning-id-range
          | word
          | quoted-string
          | num-range
          | int-range
          | hash-value
          | date-range
          | boolean
                  
set-operator : UNION 
             | INTERSECT
             | DIFFERENCE
                                 
warning-id-range : warning-id
                 | int-range
                 | group-range
                 | both-range
 
warning-id : int
           | warning-id-grouponly
           | warning-id-instonly
           | warning-id-both
                   
group-range : warning-id-grouponly..
           | ..warning-id-grouponly
           | warning-id-grouponly..warning-id-grouponly

both-range : warning-id-both..
           | ..warning-id-both
           | warning-id-both..warning-id-both

warning-id-grouponly : int.

warning-id-instonly : .int

warning-id-both: int.int

hash-value: hexadecimal number

field-condition terms

The following table shows the relationship between the warning-specific field-name values and the properties of a warning, along with the expected type of the condition part of a field-condition.

Terms involving a warning-id-range

The following table shows the different forms an id-based field-condition term can take, along with their interpretations.

similar and clustered searches

A field-condition term with field-name similar or clustered is interpreted as follows.

Terms involving a set-operator

Terms that involve a set-operator define a set of candidate matches, as described in the following table.

Important Note: Any search that includes one or more T set-operator T terms will return a result set containing at most one instance per warning group. If two or more instances of a single warning group match the search query, scope, and Visible Warnings setting, one is selected arbitrarily for inclusion in the result set.

• With active Visible Warnings (more generally, any query or Visible Warnings setting that specifies similar=false), the result set will only contain representative instances.
• With all Visible Warnings (more generally, any search where neither query nor Visible Warnings specifies similar=false), the result set may contain non-representative instances - even if representative instances of the same warning group were eligible for inclusion.
• Note that this property means that the results for query T₁ UNION T₂ are a subset of the results for T₁ OR T₂, and often a strict subset.

directory, file, and path searches

If field-name is directory, file, or path, comparison:

• is case-insensitive, and
• does not distinguish between forward slashes and backslashes.

rank and score terms

The rank and score for a warning instance are computed and stored as floating point values, although they are rounded before displaying in the GUI. The int-range conditions for rank- and score-based field-condition terms are therefore interpreted as follows.

• An isolated integer X matches all values in the interval [X-0.5, X+0.5), or [0, X+0.5).
• An integer X at the bottom of a range X.. or X..Y will be interpreted as X-0.5, or 0.
• An integer X at the top of a range W..X or ..X will be interpreted as X+0.5.

If a value lies outside the interval [0, 100] after this adjustment, it is further adjusted to the appropriate extreme of that interval.

For example:

Plain text terms: word, quoted-string, and none

Plain text search terms—word, quoted-string, and none—are compared against the following fields, with substring search.

• str is equivalent to adesc:str | aid:str | analysis:str | categories:str | class:str | detected:str | directory:str | file:str | finding:str | fingerprint:str | firstdetected:str | id:str | iid:str | language:str | line:str | line_content:str | listing:str | modified:str | notes:str | owner:str | path:str | priority:str | procedure:str | rank:str | score:str | state:str

Examples

One good source of example search language expressions is the Saved Searches page, since it lists the expression associated with each named search. Even if you haven't saved any searches yet, the page will list the expressions for active and not suppressed, which come with CodeSonar:

The following table shows simple example queries using field-names from the warning search language.

SQL Terms

The sql field-name is provided to allow extra search customization, but is not supported. It is only available to users with G_SQL_CONSOLE permission.

For a search that includes a field-condition of the form

CodeSonar will obtain search results by executing an SQL statement of the form

SELECT <your specified columns>
   FROM <CodeSonar-determined relation>
   WHERE <other-terms1 OP1> cond  <OP2 other-terms2>
   ORDER BY <your specified order>

where

• In cases where the FROM clause does not include attributes that you want to test in the WHERE clause, you will need to include a suitable EXISTS statement in cond. For example, to find warnings whose Class includes "null", you could use
  sql:"EXISTS (SELECT * from cs_warningclass where lower(label_xml) LIKE '%null%' AND cs_warningclass.id = cs_warninginstdata.warningclass_id)"
  although in this case it is much simpler to use
  class:null
• To see samples of CodeSonar's SQL queries in general and WHERE clauses in particular, use your web browser to view the source of any warning search results page. The SQL query used to obtain the results shown on the page is included in an HTML comment directly above the result table.
• The hub database schema is available for inspection at $CSONAR/codesonar/py/SCHEMA.
  You can also use the SQL Console to examine the schema programmatically.