Ending Null Pointer Crashes

Total Page:16

File Type:pdf, Size:1020Kb

Ending Null Pointer Crashes The Communications Web site, http://cacm.acm.org, features more than a dozen bloggers in the BLOG@CACM community. In each issue of Communications, we’ll publish selected posts or excerpts. Follow us on Twitter at http://twitter.com/blogCACM DOI:10.1145/3057284 http://cacm.acm.org/blogs/blog-cacm There is a NULL pointer deref- Ending Null erence in function imagetobmp of convertbmp.c:980 of OpenJPEG 2.1.2. image->comps[0].data is not assigned a Pointer Crashes value after initialization(NULL). Impact is Denial of Service. Void safety, says Bertrand Meyer, relies on Yes, that is for the JPEG standard. type declarations and static analysis. Try not think of it when you upload your latest pictures. Just for one month (November 2016), the CVE database Bertrand Meyer The problem is particularly acute contains null pointer vulnerabilities Null-Pointer Crashes, in object-oriented programming lan- affecting products of the Gotha of the No More guages, where x.f is the major com- IT industry, from Google (http://bit. http://bit.ly/2i6w0nz putational mechanism. Every single ly/2mfdAD2) and Microsoft (http:// December 20, 2016 execution of this construct (how bit.ly/2muJImD) (“theoretically every- As an earlier article5 em- many billions of them occurred in one could crash a server with just a sin- phasized, code matters; so do program- running programs around the world gle specifically crafted packet”) to Red ming languages. While Eiffel is best since you started reading this?) Hat (http://red.ht/2lXB5xS) and Cisco known for its Design by Contract tech- faces that risk. Compilers for many (http://bit.ly/2mMcueo). The entry niques, they are only part of a systematic languages catch other errors of a for an NVIDIA example (at http://bit. design all focused on enabling develop- similar nature—particularly type ly/2lUREf8) explains: ers to realize the best of their abilities— errors, such as assigning the wrong For the NVIDIA Quadro, NVS, and Ge- and eradicate from their code the sourc- kind of value to a variable—but they Force products, NVIDIA Windows GPU es of crashes and buggy behavior. do nothing about prohibiting null Display Driver R340 before 342.00 and Talking about sources of crashes, pointer dereferencing. R375 before 375.63 contains a vulner- one of the principal plagues of modern This fundamental brittleness threat- ability in the kernel mode layer (nvldd- programs is null-pointer dereferencing. ens the execution of most programs mkm.sys) handler where a NULL pointer This term denotes what happens when running today. Calling it a “billion- dereference caused by invalid user input you call x.f, meaning apply f (a field ac- dollar mistake” as Tony Hoare did1 is may lead to denial of service or potential cess or an operation) to the object that x not an exaggeration. In his recent Ph.D. escalation of privileges. references. If you want to define mean- thesis2, Alexander Kogtenkov surveyed We keep hearing complaints that ingful data structures, you need to allow the null-pointer-derefencing bugs in “the Internet was not designed with “null,” also known as Nil and Void, as the Common Vulnerabilities and Expo- security in mind.” What if the problem one of the possible values for reference sures (CVE) database, the reference re- had far less to do with the design (TCP/ variables (for example, to terminate pository of information about Internet IP is brilliant) than with the languages linked structures: the “next” field of the attacks. The resulting chart, showing that people use to write tools imple- last list element must be null, to indi- the numbers per year, is edifying: menting these protocols? cate there is no next element). But then Beyond the numbers stand real ex- In Eiffel, we decided that the situ- you should make sure that x.f never gets amples, often hair-raising. The descrip- ation was no longer tolerable. After called for null x, since there is in that tion of vulnerability CVE-2016-9113 the language had eradicated unsafe case no object to which we can apply f. (http://bit.ly/2mafdkJ) states: casts through the type system, memory 8 COMMUNICATIONS OF THE ACM | MAY 2017 | VOL. 60 | NO. 5 blog@cacm management errors through garbage Null pointer issues (such as null pointer dereferencing) in Common Vulnerabilities and collection and data races through the Exposures Database. SCOOP concurrency mechanism, null pointer dereferencing was the remain- Collected by Alexander Kogtenkov ing dragon to slay. Today Eiffel is void- from MITRE’sCVE® database safe: a null pointer dereference can 80 10-Year average simply not happen. By accepting your 70 program, the compiler guarantees that every single execution of every single x.f 60 will find x attached to an actual object, rather than void. 50 How do we do this? I am not going 40 to describe the void-safe mechanism in detail here, referring instead to the 30 online documentation6, with the warn- ing it is still being improved. But I can 20 give the basic ideas. The original article Number of null-pointer issues describing void safety (and giving cred- 10 it to other languages for some of the original ideas) was a keynote at ECOOP 2000 2002 2004 2006 2008 2010 2012 2014 2016 in 20053. Revisiting the solution some years later, I wrote4: Devising, refining, and documenting the concept behind the mechanism pre- ple) PERSON it can never be void: its Certified Attachment Patterns (CAPs), sented here took a few weeks. The engi- value will always be a reference to an which compilers must implement. The neering took four years. object of that type; p1 is “attached.” preceding example is just one such CAP. That was optimistic. Seven more This is the default. If you want p2 to ac- A formal model backed by mechanized years later, the “engineering” con- cept a void value you will declare it as proofs (using the Isabelle/HOL proof tinues. It is not a matter of ensuring detachable PERSON. Simple compile- tool) provides2 solid evidence of the void safety; the mechanism was essen- time consistency rules support this soundness of these rules, including the tially sound from the beginning. The distinction: you can assign p1 to p2, delicate parts about initialization. continued fine-tuning has to do with but not the other way around. They Void safety has been here for several facilitating the programmer’s task. ensure an “attached” declaration is years, and no one who has used it wants Any mechanism that avoids bugs—an- truthful: at runtime, p1 will always be to go back. (The conversion to voided other example is static typing—buys non-void. That is a formal guarantee safety of older, non-void-safe projects is safety and reliability at a possible from the compiler. not as painless.) Writing void-safe code cost in expressiveness: you have to The static analysis produces more quickly becomes second nature. prohibit harmful schemes (otherwise such guarantees, without particular ac- And what about your code: are you you would not avoid any bugs), but tions from the programmers as long as certain it can never produce a null- you do not want to prohibit useful the code is safe. For example, if you write pointer dereference? schemes or make them too awkward to express (otherwise it is very easy to if p2 /= Void then p2.f end References 1. Hoare, C.A.R., Null References: The Billion-Dollar remove bugs: just reject all programs!) Mistake, August 25, 2009, http://bit.ly/2lAhgeP 2. Kogtenkov, A., Void Safety, ETH Zurich Ph.D. thesis, or make them too awkward to express. we know that things are OK. (Well, un- January 2017, http://se.inf.ethz.ch/people/kogtenkov/ The “engineering” consists of ever der certain conditions. In concurrent thesis.pdf. 3. Meyer, B., Attached Types and their Application more sophisticated static analysis, programming, for example, we must to Three Open Problems of Object-Oriented through which the compiler can ac- be sure that no other thread running in Programming, in ECOOP 2005 (Proceedings of European Conference on Object-Oriented cept safe cases that simplistic rules parallel can make p2 void between the Programming, Edinburgh, 25-29 July 2005), ed. would reject. time we test it and the time we apply f. Andrew Black, Lecture Notes in Computer Science 3586, Springer, 2005, pages 1-32, http://bit.ly/2muJ8Ff In practice, the difficulty of fine- The rules take care of these conditions.) 4. Meyer, B., Kogtenkov, A., and Stapf, E.: Avoid a Void: The tunign void safety mostly involve the The actual definition cannot, of Eradication of Null Dereferencing, in Reflections on the Work of C.A.R. Hoare, eds. C. B. Jones, A.W. Roscoe and initialization of objects. While the de- course, say that “the compiler” will K.R. Wood, Springer, 2010, pages 189-211, tails of void safety can be elaborate, recognize safe cases and reject unsafe http://bit.ly/2lsNfN0 5. Meyer, B., Those Who Say Code Does Not Matter, the essential idea is simple: the mech- ones. We cannot just entrust the safety CACM, April 15, 2014, http://bit.ly/1mNqout anism relies on type declarations and of our program to the inner workings 6. Void safety documentation at eiffel.org: http://bit.ly/2lsS2xZ static analysis. of a tool (even open-source tools like The void-safe type system introduc- the existing Eiffel compilers). Besides, Bertrand Meyer is a professor of software engineering at es a distinction between “attached” there is more than just one compiler. In- Politecno di Milano and Innopolis University. and “detachable” types.
Recommended publications
  • Class Invariants: Concepts, Problems and Solutions
    Class invariants: concepts, problems and solutions Bertrand Meyer Draft 4, 22 May 2021 Groucho: That’s in every contract. That’s what they call a sanity clause. Chico: Haha! You can’t fool me. There ain’t no sanity clause. From [19] Abstract Class invariants are both a core concept of object-oriented programming and the source of the two key open OO verification problems: furtive access (particularly from callbacks) and reference leak (from aliasing). Existing approaches force on programmers an unacceptable annotation burden. This article explainfps the concept of invariant and solves both problems modularly through the O-rule, defining fundamental OO semantics, and the inhibition rule, using information hiding to remove harmful reference leaks. It also introduces the concept of tribe as a basis for other possible approaches. For all readers: this article is long because it includes a tutorial, covers many examples and dispels misconceptions. To understand the key ideas and results, however, the first page-and-a-half (section 1) suffices. For non-experts in verification: all concepts are explained; anyone with a basic understanding of object-oriented programming can understand the discussion. For experts: the main limitation of this work is that it is a paper proposal (no soundness proof, no implementation). It addresses, however, the known problems with class invariants, solving such examples as linked lists and the Observer pattern, through a simple theory and without any of the following: ownership; separation logic; universe types [34]; object wrapping and unwrapping [15]; semantic collaboration, observer specifications [39, 40]; history invariants [17]; “inc” and “coop” constructs [31]; friendship construct [3]; non-modular reasoning [25].
    [Show full text]
  • Towards Null Safety Benchmarks for Object Initialization
    Моделирование и анализ информационных систем. Т. 24, № 6 (2017), с. 718–729 Modeling and Analysis of Information Systems. Vol. 24, No 6 (2017), pp. 718–729 ○c Kogtenkov A. V., 2017 DOI: 10.18255/1818-1015-2017-6-718-729 UDC 004.052.42, 004.4’6, 004.423.42, 004.432.2, 004.438 Eiffel, 519.681.2, 519.682.1 Towards Null Safety Benchmarks for Object Initialization Kogtenkov A. V. Received September 11, 2017 Abstract. Null pointer dereferencing remains one of the major issues in modern object-oriented languages. An obvious addition of keywords to distinguish between never null and possibly null references appears to be insufficient during object initialization when some fields declared as never nullmaybe temporary null before the initialization completes. This work identifies the key reasons of the object initialization problem. It suggests scenarios and metrics to be used as the benchmarks to compare solutions of this problem. Finally, it demonstrates application of the benchmarks on the proposed solution for object initialization in Eiffel. The article is published in the author’s wording. Keywords: null pointer dereferencing, null safety, void safety, object initialization, static analysis, null safety benchmarks For citation: Kogtenkov A. V., “Towards Null Safety Benchmarks for Object Initialization”, Modeling and Analysis of Information Systems, 24:6 (2017), 718–729. On the author: Alexander V. Kogtenkov, orcid.org/0000-0003-4873-8306, Doctor of Sciences ETH Zurich Independent scientist, Podolsk, Russia, e-mail: [email protected] address for correspondence: MAIS, 14 Sovetskaya str., Yaroslavl, 150003 Russia 1. Introduction Null pointer dereferencing remains one of the major day-to-day issues in software industry.
    [Show full text]
  • Моделирование И Анализ Информационных Систем Том 24 № 6(72) 2017
    ISSN 1818–1015 (Print) ISSN 2313–5417 (Online) Министерство образования и науки Российской Федерации Ярославский государственный университет им. П. Г. Демидова МОДЕЛИРОВАНИЕ И АНАЛИЗ ИНФОРМАЦИОННЫХ СИСТЕМ Том 24 № 6(72) 2017 Основан в 1999 году Выходит 6 раз в год Главный редактор В.А. Соколов, доктор физико-математических наук, профессор, Россия Редакционная коллегия С.М. Абрамов, д-р физ.-мат. наук, чл.-корр. РАН, Россия; Л. Авено, проф., Франция; В.С. Афраймович, проф.-исследователь, Мексика; О.Л. Бандман, д-р техн. наук, Россия; В.Н. Белых, д-р физ.-мат. наук, проф., Россия; В.А. Бондаренко, д-р физ.-мат. наук, проф., Россия; С.Д. Глызин, д-р физ.-мат. наук, проф., Россия (зам. гл. ред.); А. Дехтярь, проф., США; М.Г. Дмитриев, д-р физ.-мат. наук, проф., Россия; В.Л. Дольников, д-р физ.-мат. на- ук, проф., Россия; В.Г. Дурнев, д-р физ.-мат. наук, проф., Россия; В.А. Захаров, д-р физ.-мат. наук, проф., Россия; Л.С. Казарин, д-р физ.-мат. наук, проф., Россия; Ю.Г. Карпов, д-р техн. наук, проф., Россия; С.А. Кащенко, д-р физ.-мат. наук, проф., Россия; А.Ю. Колесов, д-р физ.-мат. наук, проф., Россия; Н.А. Кудряшов, д-р физ.-мат. наук, проф., Заслуженный деятель науки РФ, Россия; О. Кушнаренко, проф., Франция; И.А. Ломазова, д-р физ.-мат. наук, проф., Россия; Г.Г. Малинецкий, д-р физ.-мат. наук, проф., Россия; В.Э. Малышкин, д-р техн. наук, проф., Россия; А.В. Михайлов, д-р физ.-мат. наук, проф., Великобритания; В.А. Непомня- щий, канд.
    [Show full text]
  • A Programming Language for Distributed Systems
    A Programming Language for Distributed Systems Pascal Weisenburger A Programming Language for Distributed Systems vom Fachbereich Informatik der Technischen Universität Darmstadt zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Dissertation von Pascal Weisenburger Referent Prof. Dr. Guido Salvaneschi Korreferent Prof. Dr. Philipp Haller Darmstadt, 2020 Pascal Weisenburger: A Programming Language for Distributed Systems Technische Universität Darmstadt Jahr der Veröffentlichung der Dissertation auf TUprints: 2020 URN: urn:nbn:de:tuda-tuprints-135006 Tag der Prüfung: 21.08.2020 Darmstadt – D 17 Veröffentlicht unter CC BY-SA 4.0 International https://creativecommons.org/licenses/by-sa/4.0/ Acknowledgements My thanks especially go to my advisor, Guido Salvaneschi, for providing me with the opportunity to work on the language presented in this thesis, giving me the freedom to explore its design and helping in shaping its ideas. I thank Mira Mezini for her support and for inspiring my interest in programming languages. I also thank Philipp Haller for being the second examiner of my thesis and his time and effort of carefully reviewing it. Furthermore, I would like to thank the remaining members of my PhD committee: Sebastian Faust, Matthias Hollick and Kirstin Peters. My special thanks go to Gudrun Harris for managing the group so smoothly, for keeping us from having to be concerned about our contracts and for saving us from most of the paperwork. I also thank my long-time office colleagues Matthias Eichholz, Mirko Köhler and Ragnar Mogk for the fruitful collaboration and the nice office atmosphere and the members Nafise Eskandani, Aditya Oak, Simon Schönwälder and Daniel Sokolowski of the RP group and the members of the STG group.
    [Show full text]
  • Eiffel 101: Language, Method and Tools
    1/47 Eiffel 101: Language, Method and Tools A basic and elementary introduction for students in EECS3311 • Develop competence in the methods and tools —in the first 3 weeks of the term • Learn by doing all the examples • Compile, run, test, debug, document and understand. Resources • http://eiffel.eecs.yorku.ca • https://www.eiffel.org/documentation Available Online in the Steacie Library 2/47 Table of Contents 1 Overview ........................................................................................................................ 3 2 Eiffel Syntax .................................................................................................................... 4 3 Start a New Project ......................................................................................................... 4 4 Launch EiffelStudio IDE and compile ................................................................................ 6 5 Run ESpec Unit Tests ....................................................................................................... 8 5.1 Unit Tests succeeds with a Green Bar ................................................................................ 10 6 Contract violations and the debugger ............................................................................ 12 7 Adding a new class NODE [G] ........................................................................................ 15 8 Void safety and class NODE [G] ..................................................................................... 17 8.1 VEVI
    [Show full text]
  • A Survey of Multitier Programming
    81 A Survey of Multitier Programming PASCAL WEISENBURGER, JOHANNES WIRTH, and GUIDO SALVANESCHI, Technische Universität Darmstadt, Germany Multitier programming deals with developing the components that pertain to different tiers in the system (e.g., client and server), mixing them in the same compilation unit. In this paradigm, the code for different tiers is then either generated at run time or it results from the compiler splitting the codebase into components that belong to different tiers based on user annotations, static analysis, types, or a combination of these. IntheWeb context, multitier languages aim at reducing the distinction between client and server code, by translating the code that is to be executed on the clients to JavaScript or by executing JavaScript on the server, too. Ultimately, the goal of the multitier approach is to improve program comprehension, simplify maintenance and enable formal reasoning about the properties of the whole distributed application. A number of multitier research languages have been proposed over the last decade, which support various degrees of multitier programming and explore different design trade-offs. In this paper, we provide an overview of the existing solutions, discuss their positioning in the design space and outline open research problems. CCS Concepts: • General and reference → Surveys and overviews; • Software and its engineering → Distributed programming languages; Domain specific languages; • Theory of computation → Dis- tributed computing models. Additional Key Words and Phrases: Multitier Languages, Tierless Languages, Distributed Programming ACM Reference Format: Pascal Weisenburger, Johannes Wirth, and Guido Salvaneschi. 2020. A Survey of Multitier Programming. ACM Comput. Surv. 53, 4, Article 81 (September 2020), 35 pages.
    [Show full text]
  • Software Design Pattern 1 Software Design Pattern
    Software design pattern 1 Software design pattern In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages. Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm. History Patterns originated as an architectural concept by Christopher Alexander as early as 1966 (c.f. "The Pattern of Streets," JOURNAL OF THE AIP, September, 1966, Vol. 32, No. 3, pp. 273-278). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year. In the following years, Beck, Cunningham and others followed up on this work.
    [Show full text]
  • Mechanically Proved Practical Local Null Safety
    A.V. Kogtenkov. Mechanically Proved Practical Local Null Safety. Trudy ISP RAN/Proc. ISP RAS, vol. 28, issue 5, 2016, pp. 27-54. mentioning null pointer dereference bugs explicitly. The distribution by years is shown in figure 1. Mechanically Proved Practical Local Null Safety A.V. Kogtenkov <[email protected]> ETH Zürich Universitätstrasse 19, 8092 Zürich, Switzerland Abstract. Null pointer dereferencing is a well-known bug in object-oriented programs. It can be avoided by adding special validity rules to a language in which programs are written. Are the rules sufficient to ensure absence of such exceptions? This work focuses on null safety for intra-procedural context where no additional type annotations are needed and formalizes the rules in Isabelle/HOL proof assistant. It then proves null-safety preservation theorem for big- step semantics in a computer-checkable way. Finally, it demonstrates that with such rules null- safe and null-unsafe semantics are equivalent. Keywords: null safety; void safety; static analysis; Eiffel; formal methods; big-step operational semantics; preservation theorem; operational semantics equivalence. Fig. 1. Null pointer issues (such as null pointer dereferencing) in Common Vulnerabilities DOI: 10.15514/ISPRAS-2016-28(5)-2 and Exposures database A solution to this problem was proposed in [15] as an extension of the type system of For citation: Kogtenkov A.V. Mechanically Proved Practical Local Null Safety. Trudy ISP Eiffel with a set of so called certified attachment patterns (CAP). Similar approach RAN/Proc. ISP RAS, vol. 28, issue 5, 2016. pp. 27-54. DOI: 10.15514/ISPRAS-2016-28(5)-2 was proposed for Spec#, but was not adopted for inclusion into C# and the Common Runtime Language because of difficulties caused by required changes in the 1.
    [Show full text]
  • Avoid a Void: the Eradication of Null Dereferencing
    Draft of a paper submitted to a planned volume in honor of Tony Hoare’s 75-th birthday, 2009. Avoid a Void: The eradication of null dereferencing Bertrand Meyer*+, Alexander Kogtenkov+, Emmanuel Stapf+ +Eiffel Software, www.eiffel.com *ETH Zurich, Chair of Software Engineering, se.ethz.ch 1 Repairing the one-billion-dollar mistake Tony Hoare recently spoke [6] about the issue of null dereferencing: I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. The present note (a modest attempt at a 75-th birthday present) describes how a statically typed object- oriented programming language has, four decades after Algol W and half a century after the appearance of NIL in Lisp, liberated its users from the scourge of null-dereferencing failures. Hoare’s statement seems to hint that just a little more care and discipline in the design of Algol W would have prevented the problem from even arising. Even in light of Hoare’s record of finding brilliantly simple solution to problems that had eluded other researchers, our experience makes us doubt that null dereferencing could have vanished at the stroke of a pen.
    [Show full text]
  • Making Void Safety Practical
    System Informatics (Системная информатика), No. 10 (2017) 45 УДК 004.052.42, 004.4’6, 004.423.42, 004.432.2, 004.438 Eiffel, 519.681.2, 519.682.1 Making void safety practical Alexander Kogtenkov (ETH Z¨urich, Switzerland; Eiffel Software, USA) Null pointer dereferencing remains one of the major issues in modern object-oriented languages. An obvious addition of keywords to distinguish between never null and possi- bly null references appears to be insufficient during object initialization when some fields declared as never null may be temporary null before the initialization completes. The proposed solution avoids explicit encoding of these intermediate states in program texts in favor of statically checked validity rules that do not depend on special conditionally non-null types. Object initialization examples suggested earlier are reviewed and new ones are presented to compare applicability of different approaches. Usability of the proposed scheme is assessed on open-source libraries with a million lines of code that were converted to satisfy the rules. Keywords: null pointer dereferencing, null safety, void safety, object initialization, static analysis, library-level modularity 1. Introduction Tony Hoare [5] called his invention of the null reference a “billion-dollar mistake”. The reason is simple: most object-oriented languages suffer from a problem of null pointer dereferencing. Even in a type-safe language, if an expression is expected to reference an existing object, it can reference none, or be null. Given that the core of object-oriented languages is in the ability to make calls on objects, if there is no object, the normal program execution is disrupted.
    [Show full text]
  • Reliable Software Technologies – Ada-Europe 2013
    ADA Volume 33 USER Number 3 September 2012 JOURNAL Contents Page Editorial Policy for Ada User Journal 138 Editorial 139 Quarterly News Digest 141 Conference Calendar 165 Forthcoming Events 170 Press Release “First ‘Ada Way’ Award Winners and ‘Try and Beat Me’ Challenge” 175 Special Contribution J. G. P. Barnes “Rationale for Ada 2012: 4 Tasking and Real-Time” 178 Ada-Europe 2012 Panels T. Vardanega, F. Gasperoni, E. Plödereder, J. M. Martínez Rodríguez, B. Meyer, A. Llemosí “What is language technology in our time” 187 J. Bundgaard, A. Rodríguez, S. Palm, R. E. Sward, J. Ruiz “Reliable software, a perspective from industry” 204 Ada Way Report R. Aguirre Reyes, A. Graziano, M. Teoli, A. Zuccato “The Ada Way: development of a soccer simulator” 212 Articles from the Industrial Track of Ada-Europe 2012 F. Dordowsky, R. Bridges, H. Tschöpe “Combining Code Generation and Ada Generics to implement a Software Product Line” 217 Ada Gems 227 Ada-Europe Associate Members (National Ada Organizations) 230 Ada-Europe 2012 Sponsors Inside Back Cover Ada User Journal Volume 33, Number 3, September 2012 138 Editorial Policy for Ada User Journal Publication Original Papers Commentaries Ada User Journal — The Journal for Manuscripts should be submitted in We publish commentaries on Ada and the international Ada Community — is accordance with the submission software engineering topics. These published by Ada-Europe. It appears guidelines (below). may represent the views either of four times a year, on the last days of individuals or of organisations. Such March, June, September and All original technical contributions are articles can be of any length – December.
    [Show full text]
  • C Nullable Int Declaration
    C Nullable Int Declaration When Jerome peruse his barbicels mythologizing not flop enough, is Amery cacophonic? Monocarpous lie-downsClancy nicker, terminatively? his laurustinuses sterilize underlaying giocoso. Is Zebulen equanimous when Maxim The short answer, it is the type nullable int How null's are handled in switch statement in C Java and. If you have sex with other programming languages like C or Java. Then you declare and nullable? Happy New C 9 Features RionIO. Notation with references within declarations of variables fields properties and methods But yet would disprove using in type parameters But that school has sailed. C nullable reference types Red Hat Developer. Nullable types The complete C tutorial. This SQL tutorial explains how thing use the SQL CREATE TABLE statement with syntax. For average case where we constitute to check if if four string contains a valid integer we can creep the method Integer parseInt and audible the exception that is thrown when each number could be parsed. For instance substance use a nullable int simply publish a variable of type int. C Nullable types GeeksforGeeks. When entire pattern variable like float is introduced by fuzzy pattern rotate it is. I presume to initialize my struct with a null value and at finish point like whether the struct is null. 212 Validating Null and Empty Strings Java Platform Enterprise. WHAT IS NULL value in C? How to C String Null. However firm is virtual data type or Swift called Optional whose default value coverage a null value nil You possess use optional when the want a variable or constant.
    [Show full text]