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

says...

I think the problem is obvious from your response. I don't think you actually bothered to look it up as I suggested. I would expect some people to make a blanket buttumption like "all the embedded world is a microwave oven", but not someone in your position. The other responses in this thread cover the details on how your belief seems flawed.

I never contended that. I contend that programmers with degrees from serious universities need to no more than the bare minimum for a narrow view of the art and science involved. I personally don't care about 36-bit hardware, and it is only a minor part of the overall suite of issues related to portable software design and implementation.

I *do* care about knowing that such issues exist and how to factor knowledge of them into software design where appropriate. If two lines of code will prevent issues, if you only knew to include them, then there is no reason to omit them, other than you are totally unaware of the problems in the first place. Sadly, that is the case for far too many in the industry. Too many programmers are hearing about buffer overruns today for the first time, even after years of working in the industry.

I can't remember when I first learned about coding to prevent them, but I think it was in the late 70s, about two weeks after soldering my first backplane together and starting to write software for it. It is certainly not a new problem, it's just one that is widely reported now due to its wider impact. When all PC's were interconnected only by floppies, serial ports or 300 baud modems, it wasn't a big deal, except to those of us that cared about programs crashing and systems being unstable despite the lack of a sharp stick in the eye due to security issues traced to the same core software problems.

The next one that is going to start making the industry look foolish if parallel programming. Threads (or something better that gets dreamed up to replace them) will become the norm once multi-core CPU designs hit the mbutt market. When that happens, a host of new bugs will begin to appear, many of them with serious security implications, and teaching new college students to fix the bugs from 10 years ago won't help them prevent the new ones from appearing. Thread safety, race conditions, deadlock, cache blocking, priority inversion, locality of reference, etc. better start being part of the vocabulary of these students before they hit the real world, or it'll make buffer overruns look like a walk in the park.

I would hope that somewhere along the way somebody would bother to teach them the basics like how many address lines are required to interface to a certain amount of memory, what interrupt service routines might be used for, or even (gasp) how to minimize accuracy loss with floating point operations. Maybe even through some interesting stuff in there, like how a Heathkit programmer named Gordon Letwin, who was hired off by Microsoft to work on BASIC interpreters, came up with a novel way of triple faulting a processor to jump out of hyperspace on protected mode CPUs. Extend that to how someday they might need to think creatively and come up with a completely unforeseen way to solve a difficult problem. It might not even involve PHP or perl, and the solution might not be available via 30 seconds of googling.

That may be asking too much from universities focused on enrollment rates and having nice buzzwords in the course breastles on their degree plan web pages, rather than successful delivery of skills so that their graduates are positioned for success later on.

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