Thou shalt have no other gods before the ANSI C standard 1370

says...

If you wanted to stir the pot, I think you found the way...

You seem to think that "real-world" means PCs. Guess how many PC's are sold a year, then guess how many embedded systems are sold a year. Or better yet, look it up. Then figure out what a wide variety of processors are used for those embedded systems.

Then come back and proselytize to us about "real-world" problems and how big ints ought to be.

Are you implying that someone that thinks at something like the VB level of complexity is more capable of understanding buffer overflows than than a qualified C programmer? Your second attempt at being inflammatory seems to be attempting to make a point (hardly defensible) that C programmers are as poorly educated on system internals as USA Today readers are on world politics. Even on the surface that seems ludicrous, as C is about as close to hardware as you get without popping out the buttembler or editing raw binaries.

Or, are you reacting to the fact that C programmers can often defend their position far more rigorously than someone that has never even heard of a course on computer systems architecture, much less attended one? This may make you angry, frustrated, etc., causing you to sling a few arrows instead of being concrete about your reasons.

That's encouraging. If every Microsoft employee had the same rate of success, 5.6 bugs per quarter (or so), then Windows might be secure by the time the Cleveland Browns win a superbowl.

It probably is too much to hope for an entire course devoted to this today, but if your students are very bright at all, it shouldn't have taken more than one lecture (at most) to get the basics across so they would have at least seen them once before they die.

Judging by the typical newbie programming questions in other newsgroups, you would be the first college professor to cover these issues in detail for at least a decade or more. There was a time when entire courses were devoted to this topic. It is quite easy to determine who has and has not attended one simply by looking at their code.

You couldn't even get out of junior division course work without being FLUENT (not just aware) of things like floating point reps, 1's compliment vs. 2's complement, numerical methods, controlling error propagation, and a host of similar issues apparently not even mentioned during a 4-year degree program anymore. That isn't providing an education, that's holding a degree mill. Those people aren't prepared for professional work, although they can probably build websites for their inlaws when they graduate.

I interviewed a recent CS grad with a high GPA who couldn't even tell me what a hash table was. He did have an idea that hashing had something to do with encrypting data, but that's about as far as he could go. AVL trees? Blank stare. How many address lines would it take to support a certain amount of memory? Bzzt. What's a finite state machine? No clue.

Ask a question about computing history, you know the stuff you once learned about the the early computers, design decisions, etc., in your HIGH SCHOOL "computer math" clbutt, and you could be talking to a palm tree and get a better response. Pathetic.

After the first one, I started asking similar questions to a lot of candidates. It was not an anomaly, it was an epidemic. If your candidate was a graduate from a US university anytime during or immediately before the .COM boom when every potential broom salesman in North America enrolled in a CS program, you were going to be sadly disappointed. If you can image it, "MIS", "CIS", & "IT" grads were an order of magnitude worse.

Teaching the buzzwords and the hot topics off of the trade rags may get enrollment up, but it is *not* preparing the next generation of college grads for doing serious development work.

-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig