On Thu, Feb 26, 2009 at 7:03 PM, Jonathan S. Shapiro <[email protected]>wrote:
> > > Yes, I've never worked on critical systems. My experience is based on how > > bindings works on the CLR, which work quite well. > > The problem for CLR is a little bit different. Most CLR languages > implement implicit integer size promotions if they have more than one > integer size. I don't think that we can do that. CLR can also use > native methods, which bypass the type system at this level. > Yes, the CLR itself has a very relaxed integer arithmetic execution model where implicit widening happens all the time, but I don't think it's worth comparing them. All uses of native methods, either thought P/Invoke, internal calls or with native code instead of IL, are type checkable. In case of bindings such as P/Invoke, the definition itself is not verifiable as it's outside of the scope of the platform - but I guess BitC is on a similar situation. Let's look at a concrete example: what does CLR specify as the return > type of the open() system call, and if it is not "int" then where and > how is that return type defined? > The CLR decouples the C types from the binding definition. You either defines it to be of a fixed width type or of a native size word. It's hard to reason about what the code do outside of those two options. Most compilers today follow a very sane definition. open could be defined as "int open (...)", and malloc could be "native int malloc (...)", for example. Making a big effort to have c_int, c_long, c_ZZZ will shift the burden of bugs from the compiler to applications.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
