1.4.7. Migration to 7.11.0

Caution

Starting with this release, the Axivion Suite now comes with its own Python interpreter that is used by default if no other interpreter is set with BAUHAUS_PYTHON. To restore the old behavior and search for a Python interpreter only on the system set BAUHAUS_PYTHON=auto. For alternatives, see BAUHAUS_PYTHON.

1.4.7.1. AxivionC#Frontend

In order to simplify configuration, the option of creating an RFG was removed from AxivionC#Frontend and parts of the configuration need manual adjustment.

What needs to be done:

• If you configured a filename with the extension .rfg in the field output, the analysis will abort with an error. Change it to use the extension .cspkg instead.

• Previously AxivionC#Frontend required the /Project/rfg option to be set to the name of the generated RFG file. This is no longer necessary and setting the option will now produce an error, if AxivionC#Frontend is used.

• If you need to specify a custom RFG output filename, you can now use the same configuration options as with C/C++ analyses. See the rule SaveRFG for more information.

1.4.7.2. Dashboard

General Settings

The General Settings page has been migrated to the new Look and Feel and divided up into subsections. The page can be accessed with administration privileges in the same manner as the old interface was accessible, via the settings menu button in the top-right section of the header-line.

Additionally, applying settings now requires explicit saving (if applicable) via the new Save button on the bottom of the settings pages.

Supplementary information, if available, can be toggled via the info-button which is located to the right of the section header.

Legacy Mailer

The per-project setting Prefer Legacy Mailer has been removed. Starting with 7.5.0, the analysis side was not looking at this setting anymore and thus was unable to use the CI-configured mailer anyway. Should you still have an analysis project using Axivion Suite version < 7.5.0 that you want to talk to a Dashboard of version >= 7.11.0 and that is configured to use the CI-based mailer configuration, you will either need to switch to the Dashboard integrated mailer or use our API to send your own notification e-mails, see, e.g., example/reports/report_delta_mailer.py. In the former case, we recommend doing the migration before updating the Dashboard and also consulting the documentation of version < 7.11.0 as it contains hints on how to do this migration.

Reports

The example report modules located in the example/reports directory have been updated to remove the outfile option. Reports are now automatically named based on the project name for which they are generated.

Note

The example modules—both visualization and report modules—in example/reports are not part of the stable API and may be subject to changes without explicit notice. It is hence recommended to copy them outside the Axivion Suite installation directory before customizing and using them. Starting with 7.11.0, the dashserver start and dashserver install commands will automatically copy all modules from example/reports to <confdir>/modules where <confdir> is the Axivion Dashboard Server configuration directory.

If you configured your Axivion Dashboard Server to search for report modules inside the Axivion Suite installation directory and rely on the outfile option, make sure to create a backup of the old modules prior to the upgrade. Moreover, if you have automated tasks that create reports through report_runner, make sure to remove the outfile option from those tasks.

1.4.7.3. Java

For running the Dashboard or viewing Local Build or Single File Analysis results we do not officially support JDK builds from jdk.java.net any more. They should continue working just fine, but if you want to stick with an explicitly recommended JVM, please have a look at our Dashboard Installation Guide.

1.4.7.4. Axivion Suite Plugin for Visual Studio Code

The Single-File Analysis settings for the Axivion Suite Plugin for Visual Studio Code now expects an array of Single File Analysis configurations, instead of a single configuration, e.g.:

Example for the migrated Axivion Visual Studio Code Plugin Single-File Analysis settings.

"axivion.singleFileAnalysis": [
    {
        "command": "${workspaceFolder}\\Axivion\\single_file_analysis_scenario_1.bat ${file}"
        "bauhausConfig": "${workspaceFolder}\\Axivion",
    },
    {
        "command": "${workspaceFolder}\\Axivion\\single_file_analysis_scenario_2.bat ${file}"
        "bauhausConfig": "${workspaceFolder}\\Axivion",
    }
]

If this array contains multiple entries, you will be prompted to select a configuration upon running a Single File Analysis in Visual Studio Code.

This change will not break existing Single File Analysis configurations, but will issue linter warnings in the configuration file.

1.4.7.5. Axivion Suite Plugin for Visual Studio

The plugin now supports Visual Studio 2026 (aka Visual Studio 18 Insiders).

The minimum .NET version required to run the plugin in Visual Studio 2017 and 2019 was increased from .NET Framework 4.6 to .NET Framework 4.6.1. Version 4.6.1 or a newer version should already be installed on the system, if the latest Windows and Visual Studio updates are installed, so nothing should change for users of the plugin.

The requirements for the plugin for Visual Studio 2022 and 2026 have not changed.

1.4.7.6. IR

The following IR classes were previously unused (the compiler did not create any nodes of these types) and have been removed in version 7.11:

• ir.Physical.PCH_File

• ir.Logical.Logical_Instruction

• ir.Logical.And_Instruction

• ir.Logical.Or_Instruction

The following classes from the Physical part were renamed:

Mapping of old PIR class names to new PIR class names

Old name	New name
Exception_Type_Definition	Exception_Type_Specification
Redundant_Exception_Type_Definition	Redundant_Exception_Type_Specification
Additional_Exception_Type_Definition	Additional_Exception_Type_Specification

1.4.7.7. Parallelism

Behavior of command line switch -j throughout the tools has been slightly altered to reduce the number of parallel processes to guarantee enough memory for each process, see section Default Parallelism for more details.

1.4.7.8. Stylechecks

FaultDetection-UseAfterFree

By default, calls to undefined (external) functions are now assumed to use all passed pointer arguments. This may lead to new or changed findings: If a new finding is reported on a call to an external function, later (existing) findings along that path are suppressed.

The following rules are also affected, as they use FaultDetection-UseAfterFree internally:

• AutosarC++17_03-M0.3.1,

• AutosarC++18_03-M0.3.1,

• AutosarC++19_03-M0.3.1,

• CWE-672,

• CWE-825,

• CWE-910,

• CertC-MEM30,

• CertC++-EXP54,

• CertC++-MEM30,

• CertC++-MEM50,

• MisraC-21.1,

• MisraC2012-21.20,

• MisraC2012-22.2,

• MisraC2012-22.6,

• MisraC2012Directive-4.1 (if execute_checks_covered_in_other_rules is enabled),

• MisraC++-0.3.1,

• MisraC++2023-25.5.3,

• MisraC++2023-6.8.1, and

• SecureCoding-5.2.

If you prefer the old behavior, you can set the new option report_read_pointer_args_in_calls_to_undefined (enabled by default) to false on any of the affected rules.

StaticSemanticAnalysis

The following style checks now work with additional precision when StaticSemanticAnalysis is activated and (depending on the rule) may report more or less findings.

• AutosarC++17_03-M0.1.1

• AutosarC++17_03-M0.1.2

• AutosarC++17_03-M0.3.2

• AutosarC++17_10-M0.1.1

• AutosarC++17_10-M0.1.2

• AutosarC++17_10-M0.3.2

• AutosarC++18_03-M0.1.1

• AutosarC++18_03-M0.1.2

• AutosarC++18_03-M0.3.2

• AutosarC++18_10-M0.1.1

• AutosarC++18_10-M0.1.2

• AutosarC++18_10-M0.3.2

• AutosarC++19_03-M0.1.1

• AutosarC++19_03-M0.1.2

• AutosarC++19_03-M0.3.2

• MisraC-14.1

• MisraC2012-2.1

• MisraC2012-17.11

• MisraC2023-2.1

• MisraC++-0.1.1

• MisraC++-0.3.2

• MisraC++2023-0.0.1

• CQM-DeadImplementation

• CertC-MSC12

• CertC++-ERR56

SecureCoding-5.2

The rule now also checks for double free as described in ISO-TS-17961.