Warp wrote:
>   Yes, you do. Maybe you didn't understand the "on every possible platform
> which your kernel can be compiled for" part?

I'm just saying that's not really well-defined in *C*. It's 
compiler-specific, not C as such.

>   The difference is probably that neither FORTH nor Ada have the same amount
> of libraries, platform support or optimizing compilers, nor are they nearly
> as popular.

True. And those things feed on each other.

>   Of course in C. And "undefined behavior" can also mean "works as desired
> in this platform".

That's what I'm distinguishing. That's why I say C, as such, isn't very good 
for that sort of thing. You can do it, but only because you look at what 
your particular compiler generated for some piece of otherwise undefined 
code, and say "yes, that's what I'd like."

> When you know what the compiler is doing, and you are
> writing platform-specific code, C allows you to do a whole lot of things
> you can't do with other languages.

I'd phrase that as "the compiler will generate code for programs without 
defined semantics that's often what you want."

>   Most DOS demos written in C used raw pointers (eg. to the VGA memory
> buffer). They worked just fine on that platform.

Maybe I'm more of a theoreticist, but "it works for me" isn't how I like to 
write kernels. ;-)

>   It means that many if not most of the "high-level" languages pay zero
> attention to memory usage.

I'm not saying every programming language is appropriate for writing 
kernels. I'm saying there are good high-level languages both more powerful 
and safer that are better than C, and I'm not sure why they're not more popular.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message