JavaScript is not currently enabled, but is required for full CodeSonar manual search and browse functionality.

If you are viewing this file in your hub's Web GUI, enable JavaScript in your browser: you will also need it for GUI functionality.

If you opened this file directly from disk, your browser may be directly suppressing JavaScript functionality: certain browsers perform this suppression on local files (but not files delivered by web servers) for security reasons.

CodeSonar® 9.2p0 CONFIDENTIAL CodeSecure Inc

CodeSonar Search Languages

CodeSonar provides a set of powerful and flexible search languages that allow searches to be as simple or as complex as required.

Introduction

CodeSonar provides a family of powerful and flexible search languages: one search language for each domain. Each of these languages allows users to specify precise constraints on one or more properties in a specific search domain, and provides basic logical operators for combining multiple conditions. Searches can thus be as simple or as complex as required.

The languages are based on a common grammar, with each search domain having its own set of field-name values and sometimes other extensions as well. The exception is the code search language, which has a slightly more constrained grammar than the others.

The grammar shared by the warning, file, code, and procedure search languages is shown below. Separate sections for the individual search languages describe their extensions to the grammar (usually involving domain-specific field-name values), along with examples and usage notes.

Grammar

The standard grammar for the CodeSonar Warning, File, Procedure, Metric, Analysis, Project, Warning Category, and User search languages is shown below. Literal strings are displayed in pink text.

(The Code search language has a more restricted grammar that is documented in its own section.)

Every search is a T.

T 1 : quoted-string
    | field-condition
    | ( T )
    | unary T
    | T binary T
    | T T
    | word
  
word 2 : (not whitespace)*   
   
quoted-string 3 : " ( word | whitespace | escape-code)* "

field-condition : field-name operator condition

ilike-condition 4: string-field =~~ word
                 | string-field =~~ quoted-string 

imatch-condition 5 : string-field =~ word
                   | string-field =~ quoted-string 

string-field : any field-name whose condition type is "word | quoted string" 

metric-tag : the tag of any file-granularity metric class (built-in or user-defined) on the hub 

field-name 6 : depends on search domain
                   
operator 7 : =
           | :
           | != 

condition : word
          | quoted-string
          | num-range
          | int-range
          | date-range
          | boolean


int-range : int?..int
          | int..int?
          | int

num-range : num?..num
          | num..num?
          | num

date-range : date?..date
           | date..date?
           | date

unary 8 :  -

binary 9 : &
         | |
          
whitespace : space
           | tab
           | line-feed
           | carriage-return
           | form-feed
           | vertical-tab

escape_code 10 :  \\    
              |  \'
              |  \"
              |  \f
              |  \n
              |  \r
              |  \t
              |  \v

int : an integer

num : a number 

date : word
     | quoted-string
     must be consistent with a date format string in the hub Date Parse Formats or Relative Date Formats list.
                          
boolean 11 : true
          | false
                 
false : 0
      | false
      | f
      | no

true : 1
     | true
     | t
     | yes
     | word

Precedence

The standard precedence rules apply.

Within T:

 () > unary > binary

Within binary:

 & > |

Notes

1 In queries of the form T T, the sub-terms T are implicitly combined with & (AND):
Term1 Term2
is equivalent to
Term1 & Term2
2 A word is a whitespace-free string of characters that is not subject to another interpretation. In particular:
  • words cannot start with - or !.

    Example: -pointer is not a word but a unary expression that matches warnings that do not contain the word pointer. To search for the literal string, use the quoted-string "-pointer".

  • words cannot contain any of the following characters.
    - ! = : < > & | ( ) ~ + * "

    Example: var1|var2 is not a word but a binary expression that matches warnings that contain either the word var1 or the word var2. To search for the literal string, use the quoted-string "var1|var2".

  • the following strings (case insensitive) are not words.
    OR AND INTERSECT UNION DIFFERENCE
    If you want to search for any of these literal strings, use a quoted-string.
  • A word on the right-hand side of a field-condition cannot contain ..

    Example: 10..20 by itself is treated as a search for the string "10..20", but line:10..20 is treated as a search for lines in the int-range 10 to 20.

  • The interpretation of none (case-insensitive) depends on the search domain.
    • For the warning, file, analysis, and project query languages, none has a special interpretation: 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)
      If you want to search for string none in one of these search domains, 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. This will give you more useful results than a plain text search for none.
    • For the code, procedure, and metric search languages, none matches only the literal string none (case-insensitive)
      (That is, it is treated as an ordinary word.)
3 quoted-strings must be delimited with double quotes (""): single quotes ('') cannot be substituted. For example, 'Unused Variable' will be treated as two words: 'Unused and Variable'.
4 In ilike-condition, an underscore ( _ ) in the pattern stands for any single character and a percent sign ( % ) matches any sequence of zero or more characters. (=~~ is equivalent to the PostgreSQL ILIKE operator).
5 The pattern is a POSIX regular expression. (=~ is equivalent to the PostgreSQL ~* operator).
6 See field-name sets for individual search languages: warning, file, code, procedure, metric, analysis, project.
7 Operators are interpreted as follows.
= case-insensitive equality (accepted alternative: ==)
!= case-insensitive non-equality
: case-insensitive membership Notes:
  • For int-range, num-range, date-range, and boolean fields, : has the same interpretation as =. For example, aid:4 will match only the analysis with Analysis ID 4, not the analyses with Analysis IDs 14 or 41.
  • If x is not a field-name, a search term of the form x:y will be interpreted as if it were the quoted-string "x:y".
  • A search term of the form x::y will always be interpreted as if it were the quoted-string "x::y", whether x is a field-name or not.
8 Unary operators are interpreted as follows. As a convenience, the search language also accepts !.
- NOT (accepted alternative: !)
Whitespace must not appear between a unary operator and its operand. For example, - AddProc will be treated as two words: - and AddProc.
9 Binary operators are interpreted as follows. As a convenience, the search language also accepts several alternatives for each. These operators are case sensitive.
& AND (accepted alternatives: &&, AND)
| OR (accepted alternatives: ||, OR)
10 Escape codes are interpreted as follows.
\\ backslash
\' single quote
\" double quotes
\f form-feed
\n line-feed
\r carriage return
\t tab
\v vertical tab
11 The following values (case-insensitive) are treated as FALSE: 0, false, f, no. All other values are treated as TRUE.
 

To report problems with this documentation, please visit https://support.codesecure.com/.