[NO REPLY] Unsafe access and tagging mechanism (rev #1, 2018-1-15)

A place of insane ideas, nothing to see here.
User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

[NO REPLY] Unsafe access and tagging mechanism (rev #1, 2018-1-15)

Postby Giovanni » Mon Jan 15, 2018 2:37 pm

In order to be able to use plain C code from Safer C it could be required to enforce access to plain C libraries overriding the safety mechanisms introduced by Safer C.

It could work as follow:

Code: Select all

/* The library exports a libfunc() with none of the Safer C attributes
   like root, async, pure, const and a global variable error_number.*/
#include <library.h>

async <isr> my_isr(void) {

  /* From here should not be possible to call non compatible functions and
     accessing global data. Making an exception knowing that there could
     be consequences.*/
  unsafe "library.h access" {
    libfunc();
    if (error_number != 0) {
      ...
    }
  }
}


A variant could be a tagging statement:

Code: Select all

tag "text" {
}


Which just associates a text description to a code block. It could be used for requirements tagging in code, something very common in industry.

Code: Select all

tag "implements [REQ_RT0014]" {
  ...
}


That optional text string is not used in any way, it could be used by the compiler to produce a report of the unsafe/tag constructs in a build:
<type>, <module>, <start line>, <end line>, <text>

For example:
unsafe, module1.c, 67, 69, "library.h access"
block_tag, module3.c, 34, 39, "implements [REQ_RT0014]"


Something to consider is using tagging also for global variables, functions, types, structures or any other construct declaration. The compiler will be able to conveniently report start..end lines of the various constructs.

Return to “Safer C”

Who is online

Users browsing this forum: No registered users and 7 guests