San Francisco: What Makes COOGL Safe?

The majority of the world's system software infrastructure is written in C or in C++. Software at risk from the unsafety of C and C++ includes: operating systems, virtual machine hypervisors, database servers, transaction monitors, application servers, web servers, file servers, backup systems, compilers, run-time systems, industrial control systems, web browsers, networking infrastructure, security, authentication, encryption... as well as applications built on top of these technologies, even if those applications are written in safe languages.

It is important that an evolutionary path exist for these systems to be reengineered, incrementally, into systems that are safer, through the use of a safe programming language for system software. COOGL (https://www.coogl.org/) intends to be that language. COOGL is very close to C, but prevents unsafe memory accesses that could be exploited to take over control of the program. It is not garbage collected. Because the language is very close to C, incrementally reengineering large C codebases into COOGL is possible.

COOGL achieves safety while preserving the ability of C to lay out data in memory; for example, a network protocol with a header followed by optional headers, variable length data, et cetera. COOGL accomplishes its safety without garbage collection.

A few safe, or safer, programming languages, such as C#, Java, Eiffel, and Go, are used at the higher levels of application programming, but the gap between C and C++ and these other languages is large, causing large bodies of system software to continue to be maintained and enhanced in C and C++ instead of being rewritten in safe languages. The fundamental problem with those safe languages is that their memory management approach, through mandatory garbage collection, and their memory safety approach, through an extremely tight type system, makes their use inappropriate as an evolutionary path for existing C and C++ code.

We'll give an overview of COOGL; explain simplicity as a language design goal; explain what makes the language safe; and finally explain how undefined behavior is dealt with.

Ramon Pantin is a systems programmer who has been writing operating system kernels, storage based and distributed file systems, and distributed job systems for many years. He currently works in the Google Android Linux Kernel team. The products he has worked on include: ScalaData filesystem and job system, Nintendo Wii U kernel, Veritas VxFS and NGFS, IBM AIX VMM on POWER pSeries, Scalio Storage Systems, Internet Cluster Corporation OS (ICCOS), Windows 2000 (bus device drivers for plug and play and power management support), IBM Workplace OS Micro Kernel (PowerPC), Tandem Integrity UNIX SVR4 and Loosely Coupled UNIX, IBM AIX RS/6000 Kernel, etc.