Mouse wrote: We're talking about embedded, real-time systems. My team and I write mostly in C but debug in assembly. We get to know almost all of the assembly that the tool chain we use will generate and we structure our C to ensure that the generated assembly matches our expectations. In cases where that causes very unusual C syntax, comments indicating the reasoning are included and there are special comment tags that remind us to check behaviors in certain areas whenever a tool chain change is required. We use a C "style" that might look rather odd to programmers that are not familiar with the reasoning behind it. In general, we disable almost all compiler attempts at optimization. If we need speed at that level, we hand assemble. There is always a delicate balance between the speed and control that we require and the potential portability and reusability that C gives us. We have all of the source to all of the libraries that we use and have no problem stepping into any library call suspected of causing trouble. We have a thorough understanding of all of the threading code (semaphores, mutexes, reader-writer locks, various levels of context swaps, etc.) that we use and we modify it (sometimes very significantly, including but not limited to special purpose schedulers and hybrid coop/preemptive swap behavior). The line between application and OS in most of our products is fuzzy if it exists at all. Anyway, I hope that you can see that, in this sort of environment, we really don't have room for programmers that "don't want to think". Bill S.