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

says...

Strange, I've been working on home automation stuff lately, and a lot of these devices are being connected to the internet. When your home, it's lighting, temperature and security settings can be accessed from a web browser, connected to an embedded solution in a wiring closet somewhere, you can be sure that it is an issue.

Even refrigerators are on networks now in places other than college laboratories.

Even if that is true, which it might be, the point of that particular statement was in reference to the diatribe about "ancient" portability issues getting in the way of security. Well, *today* people must hook up big-endian and lilttle-endian hardware across serial, network and transparently through shared filed systems without munging the data, etc. Today, people are writing code on DSP's that do not have 8-bit bytes, etc., etc., etc.

Along with that I suppose goes the discussion about ISO standard languages catering (or not) to the whims of the PC crowd. I expect C# to be written for Windows boxes. For Windows programmers, that is probably a good thing. For those that work on software that touches more than one box, it can be a royal pain, but we fortunately have other languages that are targeted at an abstract machine, rather than Wintel, and can be used portably on a plethora of hardware architectures and operating systems (or freestanding).

You are buttuming that embedded systems are not networked. That's simply not the case. Find a popular embedded processor that doesn't have a TCP-IP stack available for it.

To the point about prevalence of security holes, consider which clbutt of hardware has the most eyes looking for security holes (both on the aggressor and the defender sides) and then ask yourself if the prevalence is real, or perceived. Maybe the current fad amongst the virii writers to do anything to bash Microsoft is skewing the results away from the reality. It could very well be that many embedded devices have nasty security bugs as yet undiscovered.

It could also be that there are not nearly as many "junior" or "wannabe" coders writing software for embedded platforms, and the problem is self-correcting. Given that there is probably a lot more lines of C being downloaded into embedded processors than being used for new GUI apps for Wintel, I'd say it must not be C's fault, or the embedded market would be on fire with security bugs. Maybe the quality of the programmer *does* matter after all. :-)

One other aspect is that in the embedded market, adding 25 new bells and whistles and eye candy effects to every new software release isn't at all popular. The "functionality trumps security" problem seen in Windows is pretty much bbuttackwards to the software evolution methods used elsewhere.

I don't disagree, as currently that seems to be where the most problems *have been identified*. Let's hope it stays that way. Security holes in some embedded systems -- consider a back door into an ATM remote banking window control package -- could be very inconvenient. :-)

I suggest there isn't an A vs B problem here, as much as a "please don't ignore the rest of the universe" in your thinking problem. As I said in the other post, pretending that the issues don't exist anymore is the problem, not hijacking a course syllabus in one university. This disbelief actually causes MORE non-portable software to be written, making the problem worse over time.

Exposing students to this, even for one day out a hundred is not going to interfere with their ability to find security holes in Windows software, it would probably give them a much needed rest. On the other hand, if one student's interest is sparked by the introduction during that one day to go do more research on the other portability issues, then that will be one more than we are hatching now in the current degree plans being offered.

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