- Paperback: 432 pages
- Publisher: Addison-Wesley Professional; 1st edition (November 17, 1995)
- Language: English
- ISBN-10: 0201845199
- ISBN-13: 978-0201845198
- Product Dimensions: 6.2 x 1.1 x 9 inches
- Shipping Weight: 1.4 pounds (View shipping rates and policies)
- Average Customer Review: 11 customer reviews
- Amazon Best Sellers Rank: #1,077,074 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
C Programming FAQs: Frequently Asked Questions 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
C Programming FAQs contains more than 400 frequently asked questions about C, accompanied by definitive answers. Although this resource contains lots of useful information, it is more of a grab bag of questions and answers than a comprehensive reference.
From the Inside Flap
At some point in 1979, I heard a lot of people talking about this relatively new language, C, and the book which had just come out about it. I bought a copy of K&R, otherwise known as The C Programming Language, by Brian Kernighan and Dennis Ritchie, but it sat on my shelf for a while because I didn't have an immediate need for it (besides which I was busy being a college freshman at the time). It proved in the end to be an auspicious purchase, though, because when I finally did take it up, I never put it down: I've been programming in C ever since.
In 1983, I came across the Usenet newsgroup net.lang.c, which was (and its successor comp.lang.c still is) an excellent place to learn a lot more about C, and to find out what questions everyone else is having about C, and to discover that you may not know all there is to know about C after all. It seems that C, despite its apparent simplicity, has a number of decidedly non-obvious aspects, and certain questions come up over and over again. This book is a collection of some of those questions, with answers, based on the Frequently-Asked Questions ("FAQ") list which I began posting to comp.lang.c in May, 1990.
I hasten to add, however, that this book is not intended as a critique or "hatchet job" on the C language. It is all too easy to blame a language (or any tool) for the difficulties its users encounter with it, or to claim that a properly-designed tool "ought" to prevent its users from misusing it. It would therefore be easy to regard a book like this, with its long lists of misuses, as a litany of woes attempting to show that the language is hopelessly deficient. Nothing could be farther from the case.
I would never have learned enough about C to be able to write this book, and I would not be attempting to make C more pleasant for others to use by writing this book now, if I did not think that C was a great language or if I did not enjoy programming in it. I do like C, and one of the reasons that I teach classes in it and spend time participating in discussion about it on the Internet is that I would like to discover which aspects of C (or of programming in general) are difficult to learn or keep people from being able to program efficiently and effectively. This book represents some of what I've learned: these questions are certainly some of the ones people have the most trouble with, and the answers have been refined over a several-year period in an attempt to ensure that people don't have too much trouble with them.
A reader will certainly have trouble if there are any errors in these answers, and although the reviewers and I have worked hard to eliminate them, it can be as hard to eradicate the last error from a large manuscript as it is to stamp out the last bug in a program. I will appreciate any corrections or suggestions sent to me in care of the publisher or at the e-mail address below, and I would like to offer the customary $1.00 reward to the first finder of any error. If you have access to the Internet, you can check for an errata list (and a scorecard of the finders) at the ftp and http addresses mentioned in question 20.40.
As I hope I've made clear, this book is not a critique of the C Programming language, nor is it a critique of the book from which I first learned C, nor of that book's authors. I didn't just learn C from K&R; I also learned a lot about programming. As I contemplate my own contribution to the C programming literature, my only regret is that the present book does not live up to a nice observation made in the second edition of K&R, namely that "C is not a big language, and it is not well served by a big book." I hope that those who most deeply appreciate C's brevity and precision (and that of K&R) will not be too offended by the fact that this book says some things over and over and over, or in three slightly different ways.
Though my name is on the cover, there are a lot of people behind this book, and it's hard to know where to start handing out acknowledgments. In a sense, every one of comp.lang.c's readers (today estimated at 320,000) is a contributor: the FAQ list behind this book was written for comp.lang.c first, and this book retains the flavor of a good comp.lang.c discussion.
This book also retains, I hope, the philosophy of correct C programming which I began learning when I started reading net.lang.c. Therefore, I shall first acknowledge the posters who stand out in my mind as having most clearly and consistently articulated that philosophy: Doug Gwyn, Guy Harris, Karl Heuer, Henry Spencer, and Chris Torek. These gentlemen have displayed remarkable patience over the years, answering endless questions with generosity and wisdom. I was the one who stuck his neck out and started writing the Frequent questions down, but I would hate to give the impression that the answers are somehow mine. I was once the student (I believe it was Guy who answered my post asking essentially the present volume's question 5.10), and I owe a real debt to the masters who went before me. This book is theirs as much as mine, though I retain title to any inadequacies or mistakes I've made in the presentation.
The former on-line FAQ list grew by a factor of three in the process of becoming this book, and its growth was a bit rapid and awkward at times. Mark Brader, Vinit Carpenter, Stephen Clamage, Jutta Degener, Doug Gwyn, Karl Heuer, Joseph Kent, and George Leach read proposals or complete drafts and helped to exert some control over the process; I thank them for their many careful suggestions and corrections. Their efforts grew out of a shared wish to improve the overall understanding of C in the programming community. I appreciate their dedication.
Three of those reviewers have also been long-time contributors to the on-line FAQ list. I thank Jutta Degener and Karl Heuer for their help over the years, and I especially thank Mark Brader, who has been my most persistent critic ever since I first began posting the comp.lang.c FAQ list five years ago. I don't know how he has had the stamina to make as many suggestions and corrections as he has, and to overcome my continuing stubborn refusal to agree with some of them, even though (as I eventually understood) they really were improvements. You can thank Mark for the form of many of this book's explanations, and blame me for mangling any of them.
Additional assorted thanks: to Susan Cyr for the cover art; to Bob Dinse and Eskimo North for providing the network access which is particularly vital to a project like this; to Bob Holland for providing the computer on which I've done most of the writing; to Pete Keleher for the Alpha text editor; to the University of Washington Mathematics Research and Engineering libraries for access to their collections; and to the University of Washington Oceanography department for letting me borrow their tape drives to access my dusty old archives of Usenet postings.
Thanks to Tanmoy Bhattacharya for the example in question 11.10, to Arjan Kenter for the code in question 13.7, to Tomohiko Sakamoto for the code in question 20.31, and to Roger Miller for the line in question 11.35.
Thanks to all these people, all over the world, who have contributed to the FAQ list in various ways, by offering suggestions, corrections, constructive criticism, or other support: Jamshid Afshar, David Anderson, Tanner Andrews, Sudheer Apte, Joseph Arceneaux, Randall Atkinson, Rick Beem, Peter Bennett, Wayne Berke, Dan Bernstein, John Bickers, Gary Blaine, Yuan Bo, Dave Boutcher, Michael Bresnahan, Vincent Broman, Stan Brown, Joe Buehler, Kimberley Burchett, Gordon Burditt, Burkhard Burow, Conor P. Cahill, D'Arcy J.M. Cain, Christopher Calabrese, Ian Cargill, Paul Carter, Mike Chambers, Billy Chambless, Franklin Chen, Jonathan Chen, Raymond Chen, Richard Cheung, Ken Corbin, Ian Cottam, Russ Cox, Jonathan Coxhead, Lee Crawford, Steve Dahmer, Andrew Daviel, James Davies, John E. Davis, Ken Delong, Norm Diamond, Jeff Dunlop, Ray Dunn, Stephen M. Dunn, Michael J. Eager, Scott Ehrlich, Arno Eigenwillig, Dave Eisen, Bjorn Engsig, David Evans, Clive D.W. Feather, Dominic Feeley, Simao Ferraz, Chris Flatters, Rod Flores, Alexander Forst, Steve Fosdick, Jeff Francis, Tom Gambill, Dave Gillespie, Samuel Goldstein, Tim Goodwin, Alasdair Grant, Ron Guilmette, Michael Hafner, Tony Hansen, Elliotte Rusty Harold, Joe Harrington, Des Herriott, John Hascall, Ger Hobbelt, Dexter Holland & Co., Jos Horsmeier, Blair Houghton, James C. Hu, Chin Huang, David Hurt, Einar Indridason, Vladimir Ivanovic, Jon Jagger, Ke Jin, Kirk Johnson, Larry Jones, James Kew, Lawrence Kirby, Kin-ichi Kitano, the kittycat, Peter Klausler, Andrew Koenig, Tom Koenig, Adam Kolawa, Jukka Korpela, Ajoy Krishnan T, Markus Kuhn, Deepak Kulkarni, Oliver Laumann, John Lauro, Felix Lee, Mike Lee, Timothy J. Lee, Tony Lee, Marty Leisner, Don Libes, Brian Liedtke, Philip Lijnzaad, Keith Lindsay, Yen-Wei Liu, Paul Long, Christopher Lott, Tim Love, Tim McDaniel, Kevin McMahon, Stuart MacMartin, John R. MacMillan, Andrew Main, Bob Makowski, Evan Manning, Barry Margolin, George Matas, Brad Mears, Bill Mitchell, Mark Moraes, Darren Morby, Bernhard Muenzer, David Murphy, Walter Murray, Ralf Muschall, Ken Nakata, Todd Nathan, Landon Curt Noll, Tim Norman, Paul Nulsen, David O'Brien, Richard A. O'Keefe, Adam Kolawa, James Ojaste, Hans Olsson, Bob Peck, Andrew Phillips, Christopher Phillips, FranAois Pinard, Nick Pitfield, Wayne Pollock, Dan Pop, Lutz Prechelt, Lynn Pye, Kevin D. Quitt, Pat Rankin, Arjun Ray, Eric S. Raymond, Peter W. Richards, Eric Roode, Manfred Rosenboom, J. M. Rosenstock, Rick Rowe, Erkki Ruohtula, John Rushford, Rutabaga, Kadda Sahnine, Matthew Saltzman, Rich Salz, Chip Salzenberg, Matthew Sams, Paul Sand, David W. Sanderson, Frank Sandy, Christopher Sawtell, Jonas Schlein, Paul Schlyter, Doug Schmidt, Rene Schmit, Russell Schulz, Dean Schulze, Chris Sears, Patricia Shanahan, Raymond Shwake, Peter da Silva, Joshua Simons, Ross Smith, Henri Socha, Leslie J. Somos, David Spuler, James Stern, Bob Stout, Steve Sullivan, my sweetie Melanie Summit, Erik Talvola, Dave Taylor, Clarke Thatcher, Wayne Throop, Steve Traugott, Ilya Tsindlekht, Andrew Tucker, G'ran Uddeborg, Rodrigo Vanegas, Jim Van Zandt, Wietse Venema, Tom Verhoeff, Ed Vielmetti, Larry Virden, Chris Volpe, Mark Warren, Alan Watson, Kurt Watzka, Larry Weiss, Martin Weitzel, Howard West, Tom White, Freek Wiedijk, Dik T. Winter, Lars Wirzenius, Dave Wolverton, Mitch Wright, Conway Yee, Ozan S. Yigit, and Zhuo Zang. I have tried to keep track of everyone whose suggestions I have used, but I fear I've probably overlooked a few; my apologies to anyone whose name should be on this list, but isn't.
Finally, I'd like to thank my editor at Addison-Wesley, Debbie Lafferty, for tapping me on the electronic shoulder one day and asking if I might be interested in writing this book. I was, and you now hold it, and I hope that it may help to make C programming as pleasant for you as it is for me.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
I have seen a lot of good books on C++ on the market but there are very few good C books and this is one of them. I will bet that fewer than 5% of the C developers out there will be able to answer some the FAQs in this book.
It's too bad that not that many people know about this book but it is a real gem.
This is an excellent book. It is organised into chapters on different aspects of C, and in each chapter are dozens of FAQs that range from rather common to extremely fine-detailed. Three chapters which I particularly liked were Chapter 1 (declarations and initalisations), 3 (expressions and evaluation order), and 6 (arrays and pointers). Later chapters introduced new (at the time) concepts to me, including getopt, variable-length argument lists, and preprocessor tricks. The level of detail provided in each answer is extraordinary.
Other things I liked about the book: The index is excellent. There is a lot of discussion (spread across the FAQs) on the differences between K&R and ANSI C. (This was relevant to me because at the time, I was splitting my work between gcc and the proprietary cc compilers on DEC Ultrix and SunOS.) The style of writing is friendly and does not talk down to you. This is not a beginners' book!
Note that there is an online version, but it does not have nearly as many questions as in this book.
A lot of the questions revolve around the assembly language-like constructs in C, for pointer arithmetic. Very easy to trip up here. And also in the related area of memory (buffer) allocation.
If that is not enough to keep you busy, Summit also talks about issues of portability across different operating systems or across different versions of the same operating system. At least you usually don't have to worry about the version of C itself. For system dependencies, Summit covers both unix and MSDOS. While C and unix grew up together, a reality is that much C programming goes on under Microsoft.
The references to MSDOS in the text reflect that the book was written in 95. Though even then, Microsft was deprecating DOS in favour of its newer Windows offerings. A newer version of this book might be overdue. Where Summit would no doubt discuss C under XP.
In my opinion it is also good to read it at least once from the beginning - this gives some good insight on the language that might not always be immediately visible to beginners, or intermediate programmers who do not have years of experience behind them.
Most every C compiler these days supports some extensions and non-standard features, and some of those might be difficult to notice as non-standard. This book will also help you program in a more portable manner, and think in more standardized C.