Slashdot Mirror

You cannot beat the OpenBSD/OpenSSH coding standards, audit process, or documentation.

After reading "The Practice of Programming" (Brian W. Kernighan, Rob Pike) I thought that every current C programmer could write clean code in current projects.

I've looked at the source of OpenSSH, after seeing some strange things in the patch. You call this the product of a current "coding standard"? This is C in the 21st century?

No wonder so many people cry for ssh implementations in more secure languages.

There's a cure for that, by the way: Effective C++ by Scott Meyers. It really is exactly the thing to fix up one's C++ knowledge to what's current (I learned C++ back in 1995, using books that were already over a year old then, and compiler versions that were at least three years old).

This reminds me that I should go ask the co-worker who's been borrowing it for six months now to return it...

Studies have shown that programmer productivity, measured by lines of code over time, varies little between languages.

Great! Now let's move on to some benchmark that actually matters. Lines of code over time has never been a good benchmark. Better ones are number of bugs, time to milestone, number of milestones accomplished on time, and user satisfaction. No, none of them are perfect. Welcome to reality.

the low-level constructs that C and C++ programmers spend time managing are the same ones that can get them into trouble

Sure, if you code using no libraries and are a dumbass about it. Heck, you can avoid most of the vulnerabilities he's talking about in C++ just by using std::string. Most of the other worries can be eliminated by using decent libraries like boost (its pointer templates are great) or Loki. In C it's a bit harder, but there's secure string and memory libraries available there too (I recently poked around in vsftp which is straight C code and uses wrappers for all string functions).

There's no need to move to a different language - although I definitely agree with different languages for different purposes - but you definitely need to know how to write things properly in the language you do use.

And while he acknowledges that high-level languages aren't immune to security bugs, he also seems to forget that most high level languages are written in lower level ones (such as Perl being written in C). A mistake in the code that creates the high level code can leave the entire thing wide open and you're back to square one. On the upside you only have to patch the language. On the downside you have dozens or hundreds of vulnerable programs instead of one or two.

Of course, the author also seems to forget that not everything was written in the past two or three years. Just how old is lpr? Is rewriting it - in any language - really going to be worth it?

Finally, the author's list of vulnerable programs at the start starkly contrasts with his suggestions at the end. Of the six listed four (kernel, openssl, mysql, and glibc) are not applicable for rewriting in high level code - by the author's own admission. One of them (openssl) is not even a language issue - it's implementation. The last two could, in theory, be written in high level languages, but lpr seriously predates Perl or Python. Mutt might have been a candidate for a high level language though - so 1 out of the 6 is a viable gripe.

The author does make a good point... it's just buried in his pointless bashing of C/C++. You need to know your tools, and you need to know how to code securely. The tools can help, but if you don't code securely then all they can do is block the more egregious sins... and those are rarely the ones that get exploited (they get blocked or patched quickly).

Highschoolers haven't had the kind of education in the 12 years of school they've had that you get in the first semester of college. :P

That said, highschool books have certain requirements. College books tend to assume extensive knowledge of materials usually covered in lecture. The higher level text books build on this assumption.

Except for college computer/technical books, which start dumb and end dumb. You want O'Reilly.

I can give you some recommendations for those interested in Web Design, though.

Lie, HÃ¥kon Wium, and Bert Bos. "Cascading Style Sheets: Designing For The Web". 2nd ed. [die MLA!] http://www.awl.com/cseng ISBN 0-201-59625-3

Zeldman, Jeffrey. "Taking Your Talents to the Web". Indiana: New Riders, 2001.

Strunk, William JR., and E.B. White. "The Elements Of Style". 4th ed. Massachusetts: Longman Publishers, 2000.

O'Reilly has volumes of text books good for introduction. They're thurough, don't skimp, and don't suffer from being stuffy or making bad assumptions about the reader's knowledge, other than stated in the preface.

Honest to god, in Highschool, I'd be more concerned about bringing the standards of the core courses up a fucking decent level.

Let's try science. Quantum Physics. I've got two books on my desk here that are good enough for twelve year olds.

Wolf, Fred Alan. "Parallel Universes". New York: Touchstone, 1990.
---. "Taking The Quantum Leap". New York: Harper & Row, 1989.

For English, that "Elements Of Style" book cited above is tiny. It's 105 pages, index and contents included. It's also 5"Ã--8.25"Ã--0.5", or 13cmÃ--21cmÃ--1.5cm, to use metric. Allow students to use it on tests, carry with them everywhere. It's gold. That's your text book for English grades 9â"12.

And what the fuck is with George Orwell's 1984 and Fahrenheit 451? They weren't even allowed in the library when I left Highschool. Ridiculous.

For creative writing, I highly recommend:
Burroway, Janet. "Imaginative Writing: The Elements of Craft". New York: Longman Publishers, 2003.
Best creative writing book I've ever seen. It'll even blend in with your stuffy brown and black books, cleverly camouflaging a book with good content.

Stop talking down to your students. They're not dumb, they're just told they are by the tone of their teachers and told by their peers that's cool enough. Their parents and their teachers demand obediance, and abhor rebelious or independant thought, so their children are extremely vulnerable to suggestion by anyone who pretends authority. A good student questions. A good teacher admits their limits, knows that some of their students will be better than them, and hopes the student can surpass them, or fill in the gaps in the teacher's knowledge.

(tangent)
I had a memorable discussion with a counselor in highschool. A teacher had been wrong, and had pretty much told me to shut up when I tried to correct her. Then she sent me to the principal for "distruptive behavior". He couldn't make me understand that "she's the teacher, so she's in charge" etc, so he sent me to a counselor. She informed me about the "pecking order" and that I was at the bottom, so I should just be pecked, because she "worked hard to get where she was". Obviously, she was superior to me, and I should "grin and bear it".

I aquired my G.E.D., and I've been very happy since I started College. Opening the G.E.D. to non-vets was one of the best things the Government has done. Can you possibly imagine how much of a relief it was, to suddenly be met as a peer by the test instructor, and ever since?

Public education is not failing because it isn't offering the latest technology. Public education is failing because administrators are considered more important than teachers. Public education is failing because teachers become teachers just to be superior to 400 students for a year. Public education is failing because education is only a byproduct of the atmosphere among the staff. The pecking order comes first.

Public education would never have produced "The Elements of Style".

Advanced Programming in the Unix Environment - a bit outdated, but still good; does not cover kernel internals
The Practice of Programming - good tips related to style, algorithms & data structures, debugging, etc.
UNIX System Administration Handbook- actually shows you how to get stuff done
Concrete Mathematics - to help you understand The Art of Computer Programming

I was at the ACCU Conference that Herb mentions in his speech, and at the end of the first day there was a special last-minute session scheduled with Herb and Stan, called "Revelation on the road to redmond". It was quite interesting, and when Herb introduced the man who had implemented partial specialisation in Visual C++, there was a tremendous round of applause! And this was not a conference full of Microsoft flunkies, far from it.

The upshot is, MS have an internal build of MSVC that will compile Loki. It should be available around the end of this year.

Although I haven't read it, I've heard this book on python (Learn to Program Using Python) is useful. It is an expanded version of this web tutorial. Although it's hard to see things from a newbie perspecitve when you've been programming for a while, python does have a reputation for being easy to learn. The syntax is nice and clean, not too verbose, and the language is coherent and well designed. And the best thing is you don't have to throw it away when you graduate from newbiehood. Save the Knuths for later on in their programming journey.

Except for FORTRAN, which still kicks C's ass on numerical applications because of the "pointer problem", and yes C++ can produce code as fast as C, but it's much more difficult due to the complexity of the language.

Standard C++ fixes some of the performance problems with earlier implementations. For an eye-opener, check out Blitz++, a numerical library written in C++. It performs on par with FORTRAN, sometimes even exceeding FORTRAN's vaunted numerical speed.

Standard C++ can also be much, much faster than C. The standard sorting algorithm is a typical example. std::sort is 250% to 1000% faster than qsort according to one benchmark. It is 20% to 50% faster than a hand-coded C quicksort for a particular data type. I have seen such results elsewhere -- this is just the first page Google turned up.

Yes, std::sort is using inlining to good advantage. That's not "cheating" as some may argue. C++ (and the standard library) provide the efficiency of inlining while maintaining genericity and separation. That's what templates do. It's an intrinsic part of the language. C++ and the standard library help you reduce programmer time (less code to write) and execution time in many important cases.

C++'s combination of static typing, polymorphism and generic programming while maintaining the ability to do "traditional" C-style structured programming is really, really nice. I have my choice of options for coding particular modules and I don't need to learn three different languages to do so. One could even argue that C++ supports a fourth model: with template metaprogramming, one can write C++ code in a style that almost looks like functional programming in the sense that recursion is used exclusively and the code implements functions that do not modify any values. Granted, this form of coding is limited to compile-time values, but it can be used in lots of surprising ways to do things like generate entire class heirarchies automatically.

--

See:

"An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl"

Kernighan and Pike's The Practice of Programming (reviewed here), especially chapter 7 on performance

This comparison (just popped up from a Google search).

Obvious advice: Measure your current system, find out where it's really spending it's time.

If programmer productivity is irrelevant, you'll be hard pressed to beat well-written C. (And if wishes were horses, beggars would fly.-)

While VSTi might still take some time before they get to market, and need to get market acceptance, there are other textbooks out there, which are "sort of" time-limited. I did choose a new textbook for this Fall's computer networking class, based on a preliminary edition I had available. That book did include a companion website with additional information. Now that the final edition is out, they suddenly limit access to the first six months after purchasing. While I do understand that they do not want to open up the entire website to everyone (it contains a complete online copy of the textbook), the limit to six months is arbitrary and limiting. Outside the first six months, the right to access such simple things as errata, you have to pay $25.

I think Guillaume's nice discussion about some of the drawbacks of Gtk-- mixed memory management policy is fine as far as it goes, but I would like to add some points.

First, there are really many alternatives to choose to decide what kind of memory management to use for a C++ program. Telling is that the C++ standardization committee could only agree on one memory management class (auto_ptr<>). It uses gross hacks for ensuring the type checker does the right thing (And I'm not convinced it's right as it is).

Ok, to get to my real point, here is a list of all memory management policies I could remember having seen used in C++:

1) explicit deallocation (programmer responsible for deleting; e.g. C++ plain pointers)
2) strict ownership (e.g. a creation function returning a smart pointer )
3) transferrable ownership (e.g. auto_ptr)
4) Stack (objects created first are deleted last)
5) Static allocation (memory for object always exists)
6) no deallocation (sometimes you just can leave memory as leaks)
7) garbage collection (The garbage collector takes care of deallocation)
8) Cluster allocator (see "Ruminations on C++" by Andrew Koenig; basically objects are deallocated in clusters, and whenever the cluster is deallocated, all the objects in it are deallocated as well).
9) reference counting with explicit ref/unref.
10) Intrusive reference counting (the objects being pointed to contain a reference count)
11) Non-intrusive reference counting (the reference count is separate from the object, e.g. like boost shared_ptr template)
12) Handle-Body idiom (you write a specialized handle for managing memory for your class)
13) Container-managed (like Gtk-- manage())
14) Containment (like Gtk-- containment based solution)
15) Library-owned objects (library only returns references without ownership to users)
16) Distributed garbage collection
17) Evictor (the objects are maintained in a fixed size array, and the least used objects are deleted when new objects are created that would o verflow the array When the object is next needed after being deleted, it's re-created).
18) Copy semantics (you always do a copy)
19) Lazy copy semantics (you make a copy when you have to)
20) Reaper (The memory is scanned at fixed intervals for freed-up objects, and any objects marked to be deleted are freed).
21) Shared memory allocation
22) Persistent allocation (You mmap() some disk space for your objects, and leave it there to allow it to be used on subsequent invocations of your program)
23) Class allocator (overloading operator new and operator delete for allocating small objects efficiently)
24) Self-managed allocation (the object deallocates itself)
25) Singleton (The object is allocated when it's first used, and deallocated at the end of the program)
26) Mixture of several of the above policies

The design space for memory allocation of C++ objects is really HUGE. So it's no wonder there is some disagreement on what is the preferred way to handle memory management, especially as many of these alternatives are actually contradictory in that it is hard to combine many of these strategies.

I personally prefer auto_ptr combined with a non-intrusive reference counted pointer class and creation functions that return memory wrapped in auto_ptr. You do need some solution for putting references to objects in containers, plain auto_ptr doesn't work for that.

It is a rare book in the field of software engineering. At its core is putting coding at the forefront of software engineering (what an amazing concept!) The basic concept is that you start with a metaphor and that is enough to get you started. You design just what you need to get the tasks at hand done. One example of a metaphor used in the book is when describing a pension caclulation to be "like a spreadsheet" (I know it is a simile, but close enough :) It then expands from there - as you need more detail, you drill down into the metaphor and fill in the design. The most controversial part of XP is you write tests first, then you write the code.

Overall, very impressed with the book. Even though I don't practice extreme programming (and in case you were wondering, no, it isn't like street luge in San Francisco :) I got a lot from the book. I will take the appropriate bits and add them to my arsenal.

Definitely worth a read and at sub-200 pages and easy reading style, you can cover it all in one decent sitting. And the bibliography is an absolute blast!

I agree.

If anyone's interested in the theory behind usability, I recommend this book on Human Computer Interaction as an introduction.

Also, here are some web-sites I found useful:

- Cooper design
Excellent collection of articles, case studies and, for students who want bullet-point summaries for ease of recall, a nice list of HCI design axioms. See in particular http://www.cooper.com/design/ where there is a series of articles, including one entitled "The myth of metaphor". Cooper is also the author of two excellent books on interface design.

- Ask Tog Design
Bruce "Tog" Tognazzini developed the first version of the Apple Human Interface Guidelines in 1978, moved to Sun, and is currently lead designer at Healtheon. He has published two excellent books on interface and software design and at this web site, he answers questions and discusses interface issues with wit and insight.

- Jacob Nielsen's website
Nielsen produces a bi-weekly column on web usability and has also just published a book called Designing Web Usability: The Practice of Simplicity which is getting rave reviews. He is widely regarded as a leader in the field of web site design and usability testing.

- Interface Hall of Shame
An excellent collection of scathing but accurate reviews of user interface disasters of one sort or another. The ultimate depressing experience for any interface designer must be to end up here.

- HCI Reading List
If you want an exhaustive list of HCI reading materials, this is a good place to look. It is reasonably up-to-date (Feb 98) and has useful comments on the majority of textbooks in this area.

- University of Maryland Human-Computer Interaction Lab
The Human-Computer Interaction Lab (HCIL) at the University of Maryland conducts research on advanced user interfaces and their development processes. They study areas such as new approaches to information visualization, interfaces for digital libraries, multimedia resources for learning communities, zooming user interfaces (ZUIs), technology design methods with and for children, and instruments for evaluating user interface technologies. The director is Ben Schneiderman, author of the book "Designing the user interface".

http://www2.awl.com/cseng/ to see that Bjarne Stroustrup will be taking questions on Slashdot this week.

I learned Java with the JDK 1.1, and found two books pretty helpful. I already had been programming in other languages including C/C++ for a while, and these books helped to learn the language. Neither would be a good choice if you also needed to learn how to program at the same time.

• "Java 1.1 Certification Study Guide" by Roberts and Heller, published by Sybex.
• "Java in a Nutshell" by Flanagan, published by O'Reilly.

The certification guide has an updated version for 1.2 that I haven't read. I was also warned by people who had taken the exam that the book by Boone, "Java 1.1 Certification Exam Guide for Programmers and Developers" is one to stay away from. Apparently it is just filled with errors. (There may be an updated version that is better, but I have no intentions of buying it, so I don't know.)

I know what you mean by being overwhelmed when you go to the bookstore. There are a lot of Java books available, and most are pure garbage. For the more specific Java topics the ORA books are pretty good, but I think that the Addison Wesley books are just a bit better.

It explains what algorithms are, what complexity and the "big-O" notation are, and has a good discussion of P vs NP, and decidability.

Given this background, I suppose this book also covers the "computers can't do everything" from that angle.

here: Exception Handling: A False Sense Of Security

Or here: Exception Handling: A False Sense Of Security
Mike Osborne (not anonymous, just lazy).

here: Exception Handling: A False Sense Of Security

Or here: Exception Handling: A False Sense Of Security
Mike Osborne (not anonymous, just lazy).