Some Were Meant for C The Endurance of an Unmanageable Language Stephen Kell Computer Laboratory University of Cambridge Cambridge, United Kingdom [email protected] Abstract 1 Introduction The C language leads a double life: as an application program- While some were meant for sea, in tug-boats ming language of yesteryear, perpetuated by circumstance, ’Round the shore’s knee, and as a systems programming language which remains a (Milling with the sand, weapon of choice decades after its creation. This essay is a and always coming back to land), C programmer’s reaction to the call to abandon ship. It ques- For others, up above Is all they care to think of, tions several properties commonly held to define the experi- Up there with the birds and clouds, and ence of using C; these include unsafety, undefined behaviour, Words don’t follow. and the motivation of performance. It argues all these are in fact inessential; rather, it traces C’s ultimate strength to a —Tiny Ruins, from “Priest with Balloons” communicative design which does not fit easily within the I am not ashamed to say that I program in C, and that I usual conception of “a programming language”, but can be enjoy it. This puts me at odds with much of programming seen as a counterpoint to so-called “managed languages”. language discourse, among both researchers and influen- This communicativity is what facilitates the essential aspect tial practitioners, which holds that C is evil and must be of system-building: creating parts which interact with other, destroyed. If only we had a “safe systems programming lan- remote parts—being “alongside” not “within”. guage”! If only we could eke out a little more performance in implementations of other languages, to remove the last CCS Concepts • Software and its engineering → Gen- remaining motivation for using C! If only we could make eral programming languages; Compilers; • Social and “the industry” see the error of its ways! Then C would be professional topics → History of programming languages; eradicated, and there would be much rejoicing. I am a “systems programmer”. It doesn’t mean I hack ker- Keywords systems programming, virtual machine, man- nels, so much as that I build systems—pieces of infrastructure aged languages, safety, undefined behavior that integrate multiple interacting parts, and sit underneath application code. Programming in C feels right for doing ACM Reference Format: this; it has a viscerally distinctive feeling compared to other, Stephen Kell. 2017. Some Were Meant for C: The Endurance of an safer, higher-level languages. Certainly, today’s experience Unmanageable Language. In Proceedings of 2017 ACM SIGPLAN of programming in C remains, despite certain advances, un- International Symposium on New Ideas, New Paradigms, and Reflec- forgiving. But I have never felt C to be an encumbrance. C tions on Programming and Software (Onward!’17). ACM, New York, is not a language I use because I’m stuck with it; I use it for NY, USA, 17 pages. https://doi.org/10.1145/3133850.3133867 positive reasons. This essay explores those reasons and their apparent contrast with conventional wisdom. Permission to make digital or hard copies of all or part of this work for 2 Two Viewpoints personal or classroom use is granted without fee provided that copies The lyric from which this essay borrows its title evokes two are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights contrasting ways of being: that of the idealist who longs to for components of this work owned by others than the author(s) must be among the clouds, and that of the sea-farers who carry be honored. Abstracting with credit is permitted. To copy otherwise, or on their business on the planet’s all-too-limiting surface. republish, to post on servers or to redistribute to lists, requires prior specific The idealist in the song is a priest, who takes literally to the permission and/or a fee. Request permissions from [email protected]. clouds: one day, clutching at helium balloons, he steps off Onward!’17, October 25–27, 2017, Vancouver, Canada a cliff edge, floats up and away, and is never seen again.1 © 2017 Copyright held by the owner/author(s). Publication rights licensed to the Association for Computing Machinery. 1This is, more-or-less, the true story of Father Antonio Adelir de Carli, ACM ISBN 978-1-4503-5530-8/17/10...$15.00 whose ill-fated April 2008 balloon flight from the Brazilian city of Paranagua https://doi.org/10.1145/3133850.3133867 was a fundraising effort towards a “spiritual rest stop” for lorry drivers. 229 Onward!’17, October 25–27, 2017, Vancouver, Canada Stephen Kell Meanwhile, the tug-boats far below symbolise another way • I consider the valuable but limited paradigm of man- to live: plying their trade along the rocky shoreline that is aged languages, and argue that it is not the only way nature’s unmovable constraint. The seafarers’ perspective to achieve safe languages; in fact managedness rules is limited and earth-bound, shaped and constrained by hard out first-class communication, so cannot replace C for practicality. system-building. Managed approaches are founded on Both viewpoints are familiar to anyone interested in pro- hierarchical abstraction; I sketch an alternative “medi- gramming. The singer sympathises with the priest, as can ated” approach which is relatively heterarchical, suits we all: it is natural to dream of a better world (or language, alternative styles of program-level reasoning, but ap- or system) overcoming present earthly constraints, mov- pears just as capable of safety guarantees, albeit at the ing over and beyond the ugly realities on the ground. But level of a system and not a language (§6). the priest’s fate is not a happy one. Meanwhile, just as the • Issues of unsafety and undefined behaviour in C are tug-boat crews are doing the world’s work, the C language widely misunderstood, particularly in the extent to continues to be a medium for much of the world’s working which undefined behaviour is motivated by perfor- software—to the continued regret of many researchers. mance, and also in what pertains to implementations As researchers in language design and related topics, we of C versus to the language specification. I elaborate on face a recurring question: how much ought we to idealise this, helped by some choice words from a well-known the rocks and waves inhabited by practitioners? We can ide- system-builder and C programmer (§7). alise not only how gadgets work (machines, software), but also why particular trade-offs win out in particular cases— I’ll begin by recapping some conventional research view- including why people use C. There is much valuable work points on C that form the basis of dispute. to be done in idealised terms, on designs, or in clean-slate fashion, or atop theoretical rather than practical substrates. But the balloonist’s view does not seem to explain the en- 3 Pieces of a Debate durance of C, given its attendant problems; the sea-farers Some months back, social media conspired to point me to- seem to live in some other, incommensurable reality. To un- wards Trevor Jim’s article “C doesn’t cause buffer overflows; derstand this phenomenon, we will have to think differently. programmers cause buffer overflows” [Jim 2015]. The title is Over the remainder of the essay, I’ll argue the following ironic; the article is one of a loose series, best summarised as points (each in its own section), sharing the theme that we “don’t use C [or] C++; use safe languages” with a tone not far need to think less about languages as discrete abstractions, short of outrage. C causes huge harm; why so little impetus less hierarchically in general, and more about the systems towards change? which embody languages—seeing language implementations The advice to prefer safe languages is hard to argue with as parts of those systems, and not shying away from con- as far as it goes. The author’s credentials as a co-designer textual details associated with implementation concerns and of Cyclone [Jim et al. 2002], a safe language designed as a non-portability. Despite this prevailing preference for talking replacement for C, are no coincidence. Indeed, it is fair to be and thinking about languages in a discrete sense, I will also outraged. Untrapped buffer overflows are a ridiculous way note certain ways in which we have the habit of confusing for software to fail in the 21st century. The list continues to C’s implementations with the language itself. grow; 2014’s Heartbleed [CERT 2014] is a high-profile new • At application level, C’s continued popularity owes tip of an ancient iceberg. mostly not to performance but to a host of unglam- Could the solution be as simple as refraining from using orous yet technically hard problems in the general ar- languages that allow these errors? I contend not; at least, eas of migration, interoperation and integration. These before we can adopt this plan, we need to answer some are widely known but continue to be neglected and questions. To what extent are existing safe languages actually undervalued as topics of research per se—perhaps, I capable of expressing the things that “unsafe” languages are suggest, because they are about system design and en- used for? Is it a language that is “safe”, or an implementation gineering research (no contradiction) more than they of one? Rather than throwing away all that code, is it possible are about languages (§4).