node-dot-cpp/memory-safe-cpp

Discuss on Rule S8

Closed this issue · 1 comments

marcosbracco commented

I don't fully see all the details on how Rule S8 has to be implemented. Split from #8

[Rule S8] Out of functions declared in "library files", ONLY functions which protoypes are explicitly listed in a special safe-library header file, are allowed.

The current implementation is very naive and probably needs an upgrade. We currentrly accept a header file with a forward declaration of functions names and type names to be accepted as safe.
For the basic C library (without overloads, without templates, without member methods) this is ok.

However, going deeper than this becomes not so clear.

  • Do we need to specify every member function of a type as safe? Or just saying that a type is safe we assume all member methods are safe? and this is the same for static methods (probably not)?

  • Adding support for templates is really challenging, usually safety of a template depends on the safety (or some property) of the instantiation arguments. Declaring that a library template is safe when used with some T and not with some other Ts is at least problematic. This works for both template functions, and template types (with their template methods)

  • Function overloads. Allowing only some overloads of a function to be safe is doable but not already done. This may add complexity to safety database, because function arguments will need to be forward declared themselves. I don't see much gain in implementing this item in isolation and it will generate a lot of maintainance troubles for the safe library header.

Maybe for the time being will be simpler to define some naming convention over our own library to define what can be called by user and what not. i.e. user can't call methods that start with underscore, user can only use types in this and that namespace, etc. etc.

As I don't see how to implement a more generic solution without going into a very complex thing. Or maybe I am over complicating things and a few examples of what is really meant will help me understand.

nobugs-hare commented

Answering questions above: current assumptions go as follows:

  • all overloads with the same name are either safe or unsafe (same logic as with private/public control); unsafe constructors can be made private with unsafe public accessors
  • if type is safe, all its safe member functions STILL have to be listed explicitly. (this is a bit controversial, but let's try to play it safe ATM).
  • the whole template is either safe or unsafe; control of valid parameter types MUST be done at a different level, using either explicit enable_if<> or concepts.

Naming convention approach is BAD; let's not do it (it will be next to impossible to get rid of it later).

If the above sounds ok, please close this issue, MAKE CHANGES to STATIC-CHECKS.md, and open issue(s) to implement these.