text:
C Traps and Pitfalls
by Koenig, Andrew
Publisher: Addison-Wesley Professional
C Traps and Pitfalls > ISBN13: 9780201179286
Tools that are comfortable after experience are often more difficult to learn at first than those that feel right immediately. Student pilots start out overcontrolling, turning first flights into roller-coaster rides, until they learn how light a touch flying really requires. Training wheels on a bicycle make it easier for a novice to ride, but get in the way after that.
So it is also with programming languages. Every programming language has aspects that are most likely to cause trouble for people not yet thoroughly familiar with them. These aspects vary from one language to another, but are surprisingly constant from one programmer to another. Thus the idea of collecting them.
My first effort to collect such problems was in 1977, when I gave a talk called PL/I Traps and Pitfalls at the SHARE (IBM mainframe users' group) meeting in Washington, DC. That was shortly after I moved from Columbia University, where people used PL/I heavily, to AT&T Bell Laboratories, where people use C heavily. The decade that followed gave me ample experience in how C programmers (including me) can get themselves into trouble if they're not certain of what they're doing.
I started collecting C problems in 1985 and published the collection as an internal paper at the end of that year. The response astonished me: more than 2,000 people requested copies of the paper from the Bell Labs library. That convinced me to expand the paper into this book.
What This Book Is
C Traps And Pitfalls aims to encourage defensive programming by showing how other people, even experienced professionals, have gotten themselves into trouble. These mistakes are generally easy to avoid once seen and understood, so the emphasis is on specific examples rather than generalities.
This book belongs on your shelf if you are using C at all seriously, even if you are an expert: many of the professional C programmers who saw early drafts said things like "that bug bit me just last week!" If you are teaching a course that uses C, it belongs at the top of your supplementary reading list.
What This Book Is Not
This book is not a criticism of C. Programmers can get themselves into trouble in any language. I have tried here to distill a decade of C experience into a compact form in the hope that you, the reader, will be able to avoid some of the stupid mistakes I've made and seen others make.
This book is not a cookbook. Errors cannot be avoided by recipe. If they could, we could eliminate automobile accidents by plastering the countryside with "Drive Carefully" signs! People learn most effectively through experience--their own or someone else's. Merely understanding how a particular kind of mistake is possible is a big step on the way to avoiding it in the future.
This book is not intended to teach you how to program in C (see Kernighan and Ritchie: The C Programming Language, Second Edition , Prentice-Hall 1988), nor is it a reference manual (see Harbison and Steele: C: A Reference Manual, Second Edition , Prentice-Hall, 1987). It does not mention algorithms or data structures (see Van Wyk: Data Structures And C Programs , Addison-Wesley 1988), and only briefly discusses portability (see Horton: How To Write Portable Programs In C. , Prentice-Hall 1989) and operating system interfaces (see Kernighan and Pike: The Unix Programming Environment , Prentice-Hall 1984). The problems mentioned are real, although often shortened (for a collection of composed C problems see Feuer: The C Puzzle Book , Prentice-Hall 1982). It is neither a dictionary nor an encyclopedia; I have kept it short to encourage you to read it all.
Your Name in Lights
I'm sure I've missed some pitfalls. If you find one I've missed, please contact me via Addison-Wesley. I may well include your discovery, with an acknowledgement, in a future edition.
A Word about ANSI C
As I write this, the ANSI C standard is not yet final. It is technically incorrect to refer to "ANSI C" until the ANSI committee finishes its work. In practice, though, the ANSI standard is far enough along that nothing I say about ANSI C is likely to change. C compilers are already available that implement many of the significant improvements contemplated by the ANSI committee.
Don't worry if your C implementation does not support the ANSI function syntax mentioned here: it is easy enough to understand the parts of the examples where it matters, and you can fall into the traps described there regardless of what version of C you use.
A collection like this could not possibly have been made in isolation. People who have pointed out particular pitfalls include Steve Bellovin, Mark Brader, Luca Cardelli, Larry Cipriani, Guy Harris and Steve Johnson, Phil Karn, Dave Kristol, George W. Leach, Doug McIlroy, Barbara Moo, Rob Pike, Jim Reeds, Dennis Ritchie, Janet Sirkis, Richard Stevens, Bjarne Stroustrup, Ephraim Vishnaic, and one contributor who wishes to remain anonymous. For brevity, I've mentioned only the first person to report any particular problem to me. Of course, I doubt any of the people I've mentioned actually invented the programming errors they pointed out to me, and if they did I doubt they'd admit it! I know I've made many of them myself too, some several times.
Useful editorial suggestions came from Steve Bellovin, Jim Coplien, Marc Donner, Jon Forrest, Brian Kernighan, Doug McIlroy, Barbara Moo, Rob Murray, Bob Richton, Dennis Ritchie, Jonathan Shapiro, and several anonymous reviewers. Lee McMahon and Ed Sitar pointed out what would otherwise have ben embarrassing typographical errors in early drafts of the manuscript. Dave Prosser clarified many fine points of ANSI C for me. Brian Kernighan supplied invaluable typesetting tools and assistance.
It has been a delight to work with the people at Addison-Wesley, including Jim DeWolf, Mary Dyer, Lorraine Ferrier, Katherine Harutunian, Marshall Henrichs, Debbie Lafferty, Keith Wollman, and Helen Wythe. I'm sure they've gained from the aid of others whom I haven't met.
I am particularly grateful to the enlightened managers at AT&T Bell Laboratories who made it possible for me to write this book at all, including Steve Chappell, Bob Factor, Wayne Hunt, Rob Murray, Will Smith, Dan Stanzione, and Eric Sumner.
The title of this book was suggested by Robert Sheckley's science-fiction anthology The People Trap and Other Pitfalls, Snares, Devices and Delusions (as well as Two Sniggles and a Contrivance) , published by Dell Books in 1968.
0201179288P04062001
A member of the Software Technology Center at ATandT Bell Laboratories, Andrew Koenig has been a programmer for 20 years. While learning C, he ported the well-known adventure program from PL/I to the delight (and frustration) of computer users everywhere. More recently, he developed a toolkit for automatic software distribution, which allows a system administrator to crash dozens of machines with a single command.
1. Lexical Pitfalls.
= is not ==
& and are not && or
Greedy lexical analysis.
Integer constants.
Strings and characters.
2. Syntactic pitfalls.
Understanding function declarations.
Operators don't always have the precedence you want.
Watch those semicolons!
The switch statement.
Calling functions.
The dangling else problem.
3. Semantic pitfalls.
Pointers and arrays.
Pointers are not arrays.
Array declarations as parameters.
Eschew synecdoche.
Null pointers are not null strings.
Counting and asymmetric bounds.
Order of evaluation.
The &&, , and ! operators.
Integer overflow.
Returning a value from main.
4. Linkage.
What is a linker?
Declarations vs. definitions.
Name conflicts and the static modifier.
Arguments, parameters, and return values.
Checking external types.
Header files.
5. Library functions.
Getchar returns an integer.
Updating a sequential file.
Buffered output and memory allocation.
Using errno for error detection.
The signal function.
6. The preprocessor.
Spaces matter in macro definitions.
Macros are not functions.
Macros are not statements.
Macros are not type definitions.
7. Portability pitfalls.
Coping with change.
How big is an integer?
Are characters signed or unsigned?
Shift operators.
Memory location zero.
How does division truncate?
How big is a random number?
Case conversion.
Free first, then reallocate?
An example of portability problems.
8. Advice and answers.
Answers.
Appendix: printf, varargs, and stdarg.
The printf family.
Simple format types.
Modifiers.
Flags.
Variable field width and precision.
Neologisms.
Anachronisms.
Variable argument lists with varargs.h.
Implementing varargs.h.
stdarg.h: the ANSI varargs.h. 0201179288T04062001
Tools that are comfortable after experience are often more difficult to learn at first than those that feel right immediately. Student pilots start out overcontrolling, turning first flights into roller-coaster rides, until they learn how light a touch flying really requires. Training wheels on a bicycle make it easier for a novice to ride, but get in the way after that. So it is also with programming languages. Every programming language has aspects that are most likely to cause trouble for people not yet thoroughly familiar with them. These aspects vary from one language to another, but are surprisingly constant from one programmer to another. Thus the idea of collecting them. My first effort to collect such problems was in 1977, when I gave a talk called PL/I Traps and Pitfallsat the SHARE (IBM mainframe users'' group) meeting in Washington, DC. That was shortly after I moved from Columbia University, where people used PL/I heavily, to AT&T Bell Laboratories, where people use C heavily. The decade that followed gave me ample experience in how C programmers (including me) can get themselves into trouble if they''re not certain of what they''re doing. I started collecting C problems in 1985 and published the collection as an internal paper at the end of that year. The response astonished me: more than 2,000 people requested copies of the paper from the Bell Labs library. That convinced me to expand the paper into this book. What This Book Is C Traps And Pitfallsaims to encourage defensive programming by showing how other people, even experienced professionals, have gotten themselves into trouble. These mistakes are generally easy to avoid once seen and understood, so the emphasis is on specific examples rather than generalities. This book belongs on your shelf if you are using C at all seriously, even if you are an expert: many of the professional C programmers who saw early drafts said things like "that bug bit me just last week!" If you are teaching a course that uses C, it belongs at the top of your supplementary reading list. What This Book Is Not This book is not a criticism of C. Programmers can get themselves into trouble in any language. I have tried here to distill a decade of C experience into a compact form in the hope that you, the reader, will be able to avoid some of the stupid mistakes I''ve made and seen others make. This book is not a cookbook. Errors cannot be avoided by recipe. If they could, we could eliminate automobile accidents by plastering the countryside with "Drive Carefully"signs! People learn most effectively through experience--their own or someone else''s. Merely understanding how a particular kind of mistake is possible is a big step on the way to avoiding it in the future. This book is not intended to teach you how to program in C (see Kernighan and Ritchie: The C Programming Language, Second Edition, Prentice-Hall 1988), nor is it a reference manual (see Harbison and Steele: C: A Reference Manual, Second Edition, Prentice-Hall, 1987). It does not mention algorithms or data structures (see Van Wyk: Data Structures And C Programs, Addison-Wesley 1988), and only briefly discusses portability (see Horton: How To Write Portable Programs In C., Prentice-Hall 1989) and operating system interfaces (see Kernighan and Pike: The Unix Programming Environment, Prentice-Hall 1984). The problems mentioned are real, although often shortened (for a collection of composed C problems see Feuer: The C Puzzle Book, Prentice-Hall 1982). It is neither a dictionary nor an encyclopedia; I have kept it short to encourage you to read it all. Your Name in Lights I''m sure I''ve missed some pitfalls. If you find one I''ve missed, please contact me viaAddison-Wesley. I may well include your discovery, with an acknowledgement, in a future edition. A Word about ANSI C As I write this, the ANSI C standard is not yet final. It is technically incorrect to refer to "ANSI C" until the ANSI committee finishes its work. In practice, though, the ANSI standard is far enough along that nothing I say about ANSI C is likely to change. C compilers are already available that implement many of the significant improvements contemplated by the ANSI committee. Don''t worry if your C implementation does not support the ANSI function syntax mentioned here: it is easy enough to understand the parts of the examples where it matters, and you can fall into the traps described there regardless of what version of C you use. Acknowledgements A collection like this could not possibly have been made in isolation. People who have pointed out particular pitfalls include Steve Bellovin, Mark Brader, Luca Cardelli, Larry Cipriani, Guy Harris and Steve Johnson, Phil Karn, Dave Kristol, George W. Leach, Doug McIlroy, Barbara Moo, Rob Pike, Jim Reeds, Dennis Ritchie, Janet Sirkis, Richard Stevens, Bjarne Stroustrup, Ephraim Vishnaic, and one contributor who wishes to remain anonymous. For brevity, I''ve mentioned only the first person to report any particular problem to me. Of course, I doubt any of the people I''ve mentioned actually inventedthe programming errors they pointed out to me, and if they did I doubt they''d admit it! I know I''ve made many of them myself too, some several times. Useful editorial suggestions came from Steve Bellovin, Jim Coplien, Marc Donner, Jon Forrest, Brian Kernighan, Doug McIlroy, Barbara Moo, Rob Murray, Bob Richton, Dennis Ritchie, Jonathan Shapiro, and several anonymous reviewers. Lee McMahon and Ed Sitar pointed out what would otherwise have ben embarrassing typographical errors in early drafts of the manuscript. Dave Prosser clarified many fine points of ANSI C for me. Brian Kernighan supplied invaluable typesetting tools and assistance. It has been a delight to work with the people at Addison-Wesley, including Jim DeWolf, Mary Dyer, Lorraine Ferrier, Katherine Harutunian, Marshall Henrichs, Debbie Lafferty, Keith Wollman, and Helen Wythe. I''m sure they''ve gained from the aid of others whom I haven''t met. I am particularly grateful to the enlightened managers at AT&T Bell Laboratories who made it possible for me to write this book at all, including Steve Chappell, Bob Factor, Wayne Hunt, Rob Murray, Will Smith, Dan Stanzione, and Eric Sumner. The title of this book was suggested by Robert Sheckley''s science-fiction anthology The People Trap and Other Pitfalls, Snares, Devices and Delusions (as well as Two Sniggles and a Contrivance), published by Dell Books in 1968. 0201179288P04062001
Reviews for C Traps and Pitfalls (9780201179286)


text:
Study at UCC | Current Students | Research | Staff | Teaching & Learning | Visitors | Alumni | About UCC
UCC | UCC Library | IRIS
Redefining military memorials and commemoration and how they have changed since the 19th century with a focus on Anglo-American practice
CORA Home
UCC Theses
Name: LevesqueAM_PhD201 ...
Description: Full Text E-thesis
Description: Full Text E-thesis ...
Levesque, J. M. André
Copyright: © 2013, J. M. André Levesque.
Copyright information: http://creativecommons.org/licenses/by-nc-nd/3.0/
Related: http://library.ucc.ie/record=b2095603
Full text restriction information: No embargo required
Citation: Levesque, J. M. A. 2013. Redefining military memorials and commemoration and how they have changed since the 19th century with a focus on Anglo-American practice. PhD Thesis, University College Cork.
Supervisor(s): Cosgrave, Michael
This thesis is a study of military memorials and commemoration with a focus on Anglo-American practice. The main question is: How has history defined military memorials and commemoration and how have they changed since the 19th century. In an effort to resolve this, the work examines both historic and contemporary forms of memorials and commemoration and establishes that remembrance in sites of collective memory has been influenced by politics, conflicts and religion. Much has been written since the Great War about remembrance and memorialization; however, there is no common lexicon throughout the literature. In order to better explain and understand this complex subject, the work includes an up-to-date literature review and for the first time, terminologies are properly explained and defined. Particular attention is placed on recognizing important military legacies, being familiar with spiritual influences and identifying classic and new signs of remembrance. The thesis contends that commemoration is composed of three key principles – recognition, respect and reflection – that are intractably linked to the fabric of memorials. It also argues that it is time for the study of memorials to come of age and proposes Memorialogy as an interdisciplinary field of study of memorials and associated commemorative practices. Moreover, a more modern, adaptive, General Classification System is presented as a means of identifying and re-defining memorials according to certain groups, types and forms. Lastly, this thesis examines how peacekeeping and peace support operations are being memorialized and how the American tragic events of 11 September 2001 and the war in Afghanistan have forever changed the nature of memorials and commemoration within Canada and elsewhere. This work goes beyond what has been studied and written about over the last century and provides a deeper level of analysis and a fresh approach to understanding the field of Memorialogy.
College of Arts, Celtic Studies and Social Sciences - Doctoral Theses [426]
History - Doctoral Theses [48]
Doctoral Theses [1613]
Except where otherwise noted, this item's license is described as © 2013, J. M. André Levesque.
Multistabilities and symmetry-broken one-color and two-color states in closely coupled single-mode lasers
Clerkin, Eoin; O'Brien, Stephen P.; Amann, Andreas (American Physical Society, 2014-03-26)
We theoretically investigate the dynamics of two mutually coupled, identical single-mode semi-conductor lasers. For small separation and large coupling between the lasers, symmetry-broken one-color states are shown to be ...
Latching dynamics in neural networks with synaptic depression
Aguilar, Carlos; Chossat, Pascal; Krupa, Martin; Lavigne, Frederic (Public Library of Science, 2017)
Prediction is the ability of the brain to quickly activate a target concept in response to a related stimulus (prime). Experiments point to the existence of an overlap between the populations of the neurons coding for ...
Media and Memory, by Joanne Garde-Hansen
Caoduro, Elena (Film Studies, University College Cork, 2012)
Search CORA
All of CORA
Communities A-Z
Keyword / Subject
CORA information
About CORA
How to submit your research
How to submit your UCC thesis
Benefits of archiving in CORA
Most Popular Authors
For information or help contact the IR Manager at UCC Library, email:cora@ucc.ie or Tel. +353 21 420 5109. Feedback Password Login
Dspace Software Copyright © 2002-2008 The DSpace Foundation
This website uses cookies. By using this website, you consent to the use of cookies in accordance with the UCC Privacy and Cookies Statement. For more information about cookies and how you can disable them, visit our Privacy and Cookies statement

redpajama_set_name: RedPajamaCommonCrawl