Opened 4 years ago

Closed 2 years ago

#17161 closed enhancement (wontfix)

Conform to C++ Core Guidelines for C?

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: security, c++, c-style maybe-bad-idea
Cc: isis, mcs Actual Points:
Parent ID: Points: large
Reviewer: Sponsor:

Description

Every so often we daydream about a Tor reimplementation in a memory-safe language (Java, Javascript, Golang, Rust, etc). Several of these have even been attempted.

However, it seems as though the C++ community wants to join the club. They are working on machine-enforceable subset of C++ that is meant to be safe(r) and fast:
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

At minimum, it seems as though we should conform to this rule:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rcpl-subset

There's a ton of things in the tor source code like "int private", "static char zeroes[32];", bad autoconf tests, and so on that prevent tor from even compiling with a C++ compiler. We should fix these, even if we we're not ready to accept C++ code in tor.

We should also discuss what we think about eventually allowing pieces of tor to be written in C++ (if nothing else for access to STL data structures and RAII), especially if the C++ Core Guidelines effort ends up producing something that does end up having safety properties that can be enforced by the compiler.

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by nickm

Hm. My first thought is that I don't mind renaming variables like 'class' and 'private', but that implicit-cast-to-void* and implicit-cast-from-void* are my friends and I would hate to have to euthanize them.

comment:2 Changed 4 years ago by isis

Cc: isis added

No prescient advice yet, other than that it would have been really nice to do the circuit type I just wrote for #7144 as a C++ class, and that at least once-per-day while writing the patch that I wished it was in C++.

comment:3 in reply to:  1 Changed 4 years ago by isis

Replying to nickm:

Hm. My first thought is that I don't mind renaming variables like 'class' and 'private', but that implicit-cast-to-void* and implicit-cast-from-void* are my friends and I would hate to have to euthanize them.


Would it work to just find whichever g++ flag to relax the errors for now, and then start requiring casts in new code to be explicit?


Rather than compile it all with g++, the way I imagined that this would be done is use g++/gcc to separately compile the different parts of the code, then link the object files, and place the following restrictions for each set of code:

  • C++ people need to provide well-written, externed, C-like functions for the C people to use.
  • C people need to be extra careful to deal with pointers to C++ safely.

And probably several other restrictions/conventions for both. Unfortunately, this sort of requires all C++ people to be good ABI designers… which… seems overly-optimistic. And it requires the C people to read C++ everytime they want to use something from it… which seems unfair.

comment:4 Changed 4 years ago by mcs

Cc: mcs added

comment:5 Changed 4 years ago by dgoulet

Milestone: Tor: unspecified
Points: large

comment:6 Changed 2 years ago by nickm

Keywords: 028-triage removed

comment:7 Changed 2 years ago by nickm

Keywords: c++ c-style maybe-bad-idea added; flamewar holywar jihad Coup++ seriously-not-trolling-xkeyscore removed
Severity: Normal

comment:8 Changed 2 years ago by mikeperry

Resolution: wontfix
Status: newclosed

Closing this since there has not been much movement on a safe subset of C++, and we're going to look into Rust first for this purpose.

Note: See TracTickets for help on using tickets.