DOCSLIB.ORG

Some Were Meant for C the Endurance of an Unmanageable Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Some Were Meant for C the Endurance of an Unmanageable Language 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).
Load more

Recommended publications
  • The Cathedral and the Bazaar Eric Steven Raymond Thyrsus Enterprises [
    The Cathedral and the Bazaar Eric Steven Raymond Thyrsus Enterprises [http://www.tuxedo.org/~esr/] <[email protected]> This is version 3.0 Copyright © 2000 Eric S. Raymond Copyright Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0. $Date: 2002/08/02 09:02:14 $ Revision History Revision1.57 11September2000 esr New major section “How Many Eyeballs Tame Complexity”. Revision1.52 28August2000 esr MATLAB is a reinforcing parallel to Emacs. Corbatoó & Vyssotsky got it in 1965. Revision1.51 24August2000 esr First DocBook version. Minor updates to Fall 2000 on the time-sensitive material. Revision1.49 5May2000 esr Added the HBS note on deadlines and scheduling. Revision1.51 31August1999 esr This the version that O’Reilly printed in the first edition of the book. Revision1.45 8August1999 esr Added the endnotes on the Snafu Principle, (pre)historical examples of bazaar development, and originality in the bazaar. Revision 1.44 29 July 1999 esr Added the “On Management and the Maginot Line” section, some insights about the usefulness of bazaars for exploring design space, and substantially improved the Epilog. Revision1.40 20Nov1998 esr Added a correction of Brooks based on the Halloween Documents. Revision 1.39 28 July 1998 esr I removed Paul Eggert’s ’graph on GPL vs. bazaar in response to cogent aguments from RMS on Revision1.31 February101998 esr Added “Epilog: Netscape Embraces the Bazaar!” Revision1.29 February91998 esr Changed “free software” to “open source”. Revision1.27 18November1997 esr Added the Perl Conference anecdote. Revision 1.20 7 July 1997 esr Added the bibliography.
    [Show full text]
  • Hints and Principles for Computer System Design Butler Lampson May 14, 2021
    Hints and Principles for Computer System Design Butler Lampson May 14, 2021 Abstract This new long version of my 1983 paper suggests the goals you might have for your system— Simple, Timely, Efficient, Adaptable, Dependable, Yummy (STEADY)—and techniques for achieving them—Approximate, Incremental, Divide & Conquer (AID). It also gives some princi- ples for system design that are more than just hints, and many examples of how to apply the ideas. Table of Contents 1. Introduction 3 1.1 Oppositions and slogans 4 2. Principles 6 2.1 Abstraction 6 2.1.1 Safety and liveness 8 2.1.2 Operations 9 2.2 Writing a spec 9 2.2.1 Leaky specs and bad specs 12 2.2.2 Executable specs 13 2.3 Writing the code: Correctness 13 2.3.1 Types 16 2.3.2 Languages 16 2.4 Modules and interfaces 17 2.4.1 Classes and objects 18 2.4.2 Layers and platforms 20 2.4.3 Components 21 2.4.4 Open systems 21 2.4.5 Robustness 22 2.4.6 Standards 23 2.5 Points of view 23 2.5.1 Notation 24 3. Goals and Techniques 25 3.1 Overview 25 3.1.1 Goals 25 3.1.2 Techniques 26 3.2 Simple 27 3.2.1 Do one thing well 27 3.2.2 Brute force 29 3.2.3 Reduction 30 3.3 Timely 30 3.4 Efficient 31 3.4.1 Before the ABCs 31 3.4.2 Algorithms 36 3.4.3 Approximate 37 3.4.4 Batch 42 1 3.4.5 Cache 43 3.4.6 Concurrency 44 3.5 Adaptable 50 3.5.1 Scaling 51 3.5.2 Inflection points 52 3.6 Dependable 53 3.6.1 Correctness 55 3.6.2 Retry 56 3.6.3 Replication 57 3.6.4 Detecting failures: real time 59 3.6.5 Recovery and repair 60 3.6.6 Transactions 60 3.6.7 Security 61 3.7 Yummy 64 3.7.1 User interfaces 64 3.8 Incremental 66 3.8.1 Being and becoming 66 3.8.2 Indirection 70 4.
    [Show full text]
  • The Cathedral and the Bazaar
    The Cathedral and the Bazaar by Eric S. Raymond D ate : 1997=09=1522 : 48 : 58 I anatomize a successful free-software project, fetchmail, that was run as a delib erate test of some surprising theories ab out software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally di erent development styles, the \cathedral" mo del of FSF and its imitators versus the \bazaar" mo del of the Linux world. I show that these mo dels derive from opp osing assumptions ab out the nature of the software-debugging task. I then make a sustained argument from the Linux exp erience for the prop osition that \Given enough eyeballs, all bugs are shallow", suggest pro ductive analogies with other self-correcting systems of sel sh agents, and conclude with some exploration of the implications of this insight for the future of software. Contents 1 The Cathedral and the Bazaar 2 2 The Mail Must Get Through 2 3 The Imp ortance of Having Users 5 4 Release Early, Release Often 5 5 When Is A Rose Not A Rose? 8 6 Pop client b ecomes Fetchmail 9 7 Fetchmail Grows Up 11 8 AFew More Lessons From Fetchmail 12 9 Necessary Preconditions for the Bazaar Style 13 10 The So cial Context of Free Software 14 11 Acknowledgements 17 12 For Further Reading 17 13 Version Id : cathedr al paper:sg ml ; v 1:241997=09=1522 : 48 : 58esr E xpesr 18 1. The Cathedral and the Bazaar 2 1 The Cathedral and the Bazaar Linux is subversive.
    [Show full text]
  • Unix Philosophy 2020
    Unix Philosophy 2020 Casper Ti. Vector <[email protected]> https://gitea.com/CasperVector/up2020 2019-08/2019-09; version 0.1.4 Contents Foreword 3 How to read this document 4 01 An introduction to the history of Unix 5 02 A taste of shell scripting 6 03 Cohesion and coupling in software engineering 7 04 Do one thing and do it well 9 05 fork() and exec() 10 06 From Unix to Plan 9 12 07 Unix philosophy: minimising the system’s complexity 13 08 Unix philosophy and software quality 16 09 Unix philosophy and software security 18 10 Unix philosophy and free / open-source software 20 11 Practical minimalism: a developer’s perspective 23 12 Practical minimalism: a user’s perspective 26 13 Hilbert’s 24th problem: minimalism in mathematics 30 14 Boltzmann’s formula: an axiom or a theorem? 31 1 15 Kolmogorov complexity and knowledge organisation 32 16 Minimalism in science and technology 33 17 Minimalism in scientific and non-scientific theories 34 18 Minimalism as an aesthetic in literature and arts 35 19 Minimalism from a cognitive perspective 36 20 Limits to application of Unix philosophy in society 38 21 Minimalism for the average person 39 22 From Lisp to Scheme 42 23 S-expressions and homoiconicity 44 24 The New Jersey and MIT / Stanford styles 47 25 Benefits of reconciling Unix and Lisp 48 26 Lisp / C reconciliation: how to? 49 27 Toward a “theory of everything” 51 References 52 Afterword 61 2 Foreword I began learning Linux in the end of 2008, and using it in the beginning of 2009; I have always used Linux as my main operating system thereafter.
    [Show full text]
  • Hints and Principles for Computer System Design 1 Introduction
    Hints and Principles for Computer System Design Butler Lampson September 12, 2019 Abstract This new long version of my 1983 paper suggests the goals you might have for your system— Simple, Timely, Efficient, Adaptable, Dependable, Yummy (STEADY)—and effective techniques for achieving them—Approximate, Incremental, Divide & Conquer (AID). It gives a few princi- ples for system design that are more than just hints, and many examples of how to apply the hints and principles. 1 Introduction There are three rules for writing a novel. Unfortunately, no one knows what they are. —Somerset MaughamQ48 You got to be careful if you don’t know where you’re going, because you might not get there. — Yogi BerraQ8 If I have seen farther, it is by standing on the shoulders of giants. —Bernard of ChartresQ7 The quest for precision, in words or concepts or meanings, is a wild goose chase. —Karl PopperQ61 Shakespeare wrote better poetry for not knowing too much; Milton … knew too much finally for the good of his poetry. —WhiteheadQ87 In 1983 I wrote a paper on “Hints for Computer System Design” for the Symposium on Operating System Principles.R45 I reread that paper every two or three years, and for more than 15 years I saw no reason to rewrite or extend it; I had written what I knew about personal distributed com- puting, operating systems, languages, networking, databases, and fault tolerance, and computer systems were continuing the work of the 1970s on these things. But since the mid-1990s the Inter- net, mobile phones, the World Wide Web, search engines, social media, electronic commerce, malware, phishing, robots and the Internet of Things have become part of the fabric of everyday life, and concurrency and scaling are now dominant themes in systems.
    [Show full text]
  • Holy Wars Essay by Marc De Bruijn MA Media Design Piet Zwart Institute, 2006 H 2 Holy Wars the Right Thing Or Worse Is Better?! 01
    Holy Wars Essay by Marc de Bruijn MA Media Design Piet Zwart Institute, 2006 H 2 Holy Wars The Right Thing or Worse is Better?! 01 The Internet has always been a place of vivid discussion. In the early days people exchanged ideas on mailing lists, local BBSs (Bulletin Board Systems) and later on Usenet. The coming of the World Wide Web ignited a rapid growth in user communities who are actively discussing many different topics. Quite often heated debates evolve into so called “holy wars”. “holy wars: n. [from Usenet, but may predate it; common] n. flame wars over religious issues. The paper by Danny Cohen that popularized the terms big-endian and little-endian in connection with the LSB-first/MSB- first controversy was entitled On Holy Wars and a Plea for Peace.” (Eric S. Raymond, “Jargon File version 4.4.7”, http://catb.org/jargon, 2003) First some background to the phenomenon. Multics (Multiplexed Information and Computing Service) was an operating system developed at MIT (Massachusetts Institute of Technology), with the help from General Electric and Bell Labs from 1965 until 2000. It was intended to be a commercial operating system for General Electric, but it only got to that status when Honeywell International took over the project. After Bell Labs and General Electric pulled out of the project, Ken Thompson – a former employee of Bell Labs – went on to create UNICS (Uniplexed Information and Computing System), together with Dennis Ritchie and a team of developers. UNICS eventually became UNIX and the basis of every GNU/Linux and BSD system.
    [Show full text]
  • The Cathedral and the Bazaar
    ,title.21657 Page i Friday, December 22, 2000 5:39 PM The Cathedral and the Bazaar Musings on Linux and Open Source by an Accidental Revolutionary ,title.21657 Page ii Friday, December 22, 2000 5:39 PM ,title.21657 Page iii Friday, December 22, 2000 5:39 PM The Cathedral and the Bazaar Musings on Linux and Open Source by an Accidental Revolutionary Eric S. Raymond with a foreword by Bob Young BEIJING • CAMBRIDGE • FARNHAM • KÖLN • PARIS • SEBASTOPOL • TAIPEI • TOKYO ,copyright.21302 Page iv Friday, December 22, 2000 5:38 PM The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, Revised Edition by Eric S. Raymond Copyright © 1999, 2001 by Eric S. Raymond. Printed in the United States of America. Published by O’Reilly & Associates, Inc., 101 Morris Street, Sebastopol, CA 95472. Editor: Tim O’Reilly Production Editor: Sarah Jane Shangraw Cover Art Director/Designer: Edie Freedman Interior Designers: Edie Freedman, David Futato, and Melanie Wang Printing History: October 1999: First Edition January 2001: Revised Edition This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later. (The latest version is presently available at http://www.opencontent.org/openpub/.) Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivatives of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder. The O’Reilly logo is a registered trademark of O’Reilly & Associates, Inc.
    [Show full text]
  • The UNIX- HATERS Handbook
    The UNIX- HATERS Handbook The UNIX- HATERS Handbook “Two of the most famous products of Berkeley are LSD and Unix. I don’t think that is a coincidence.” Edited by Simson Garfinkel, Daniel Weise, and Steven Strassmann ® PROGRAMMERS IDG Illustrations by John Klossner BOOKS PRESS iv IDG Books Worldwide, Inc. An International Data Group Company San Mateo, California • Indianapolis, Indiana • Boston, Massachusetts The UNIX-HATERS Handbook Published by IDG Books Worldwide, Inc. An International Data Group Company 155 Bovet Road, Suite 310 San Mateo, CA 94402 Copyright 1994 by IDG Books Worldwide. All rights reserved. No part of this book (including interior design, cover design, and illustrations) may be reproduced or transmitted in any form, by any means, (electronic, photocopying, recording, or otherwise) without the prior written permission of the publisher. ISBN 1-56884-203-1 Printed in the United States of America First Printing, May, 1994 10 9 8 7 6 5 4 3 2 1 Distributed in the United States by IDG Books Worldwide, Inc. Distributed in Canada by Macmillan of Canada, a Division of Canada Publishing Corporation; by Computer and Technical Books in Miami, Florida, for South America and the Caribbean; by Longman Singapore in Singapore, Malaysia, Thailand, and Korea; by Toppan Co. Ltd. in Japan; by Asia Computerworld in Hong Kong; by Woodslane Pty. Ltd. in Australia and New Zealand; and by Transword Publishers Ltd. in the U.K. and Europe. For information on where to purchase IDG’s books outside the U.S., contact Christina Turner at 415-312-0633. For information on translations, contact Marc Jeffrey Mikulich, Foreign Rights Manager, at IDG Books Worldwide; FAX number: 415-358-1260.
    [Show full text]
  • The Art of Unix Programming by Eric Steven Raymond the Art of Unix Programming by Eric Steven Raymond Copyright © 2003 Eric S
    The Art of Unix Programming by Eric Steven Raymond The Art of Unix Programming by Eric Steven Raymond Copyright © 2003 Eric S. Raymond This book and its on-line version are distributed under the terms of the Creative Commons Attribution-NoDerivs 1.0 license, with the additional proviso that the right to publish it on paper for sale or other for-profit use is reserved to Pearson Education, Inc. A reference copy of this license may be found at http://creativecommons.org/licenses/by-nd/1.0/legalcode. AIX, AS/400, DB/2, OS/2, System/360, MVS, VM/CMS, and IBM PC are trademarks of IBM. Alpha, DEC, VAX, HP-UX, PDP, TOPS-10, TOPS-20, VMS, and VT-100 are trademarks of Compaq. Amiga and AmigaOS are trademarks of Amiga, Inc. Apple, Macintosh, MacOS, Newton, OpenDoc, and OpenStep are trademarks of Apple Computers, Inc. ClearCase is a trademark of Rational Software, Inc. Ethernet is a trademark of 3COM, Inc. Excel, MS-DOS, Microsoft Windows and PowerPoint are trademarks of Microsoft, Inc. Java. J2EE, JavaScript, NeWS, and Solaris are trademarks of Sun Microsystems. SPARC is a trademark of SPARC international. Informix is a trademark of Informix software. Itanium is a trademark of Intel. Linux is a trademark of Linus Torvalds. Netscape is a trademark of AOL. PDF and PostScript are trademarks of Adobe, Inc. UNIX is a trademark of The Open Group. The photograph of Ken and Dennis in Chapter 2 appears courtesy of Bell Labs/Lucent Technologies. The epigraph on the Portability chapter is from the Bell System Technical Journal, v57 #6 part 2 (July-Aug.
    [Show full text]
  • 13 Complexity
    13 Complexity: As Simple As Possible, but No Simpler Everything should be made as simple as possible, but no simpler. —Albert Einstein At the end of Chapter 1, we summarized the Unix philosophy as “Keep It Simple, Stupid!”. Throughout the Design section, one of the continuing themes has been the importance of keeping designs and implementations as simple as possible. But what is “as simple as possible”? How do you tell? We’ve held off on addressing this question until now because understanding sim- plicity is complicated. It needs some of the ideas we developed earlier in the Design section, especially in Chapter 4 and Chapter 11, as background. The large questions in this chapter are central preoccupations of the Unix tradition, some of them motivating holy wars that have simmered for decades. This chapter starts from established Unix practice and vocabulary, then goes a bit further beyond it than we do in the rest of the book. We don’t try to develop simple answers to these questions, because there aren’t any—but we can hope that you will walk away with better conceptual tools for developing your own answers. 297 298 Chapter 13 Complexity 13.1 Speaking of Complexity As with previous issues about modularity and interface design, Unix programmers react to a set of distinctions they have often learned from experience without knowing how to articulate. Therefore we’ll need to start by developing some terminology. We will start by defining what software complexity is. We will make some hori- zontal distinctions between different flavors of complexity, which sometimes have to be traded off against each other.
    [Show full text]