<br><br><div class="gmail_quote">On Thu, Feb 26, 2009 at 7:03 PM, Jonathan S. Shapiro <span dir="ltr"><<a href="mailto:shap@eros-os.com">shap@eros-os.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> Yes, I've never worked on critical systems. My experience is based on how<br>
> bindings works on the CLR, which work quite well.<br>
<br>
</div>The problem for CLR is a little bit different. Most CLR languages<br>
implement implicit integer size promotions if they have more than one<br>
integer size. I don't think that we can do that. CLR can also use<br>
native methods, which bypass the type system at this level.<br>
</blockquote><div><br>Yes, the CLR itself has a very relaxed integer arithmetic execution model where<br>implicit widening happens all the time, but I don't think it's worth comparing them.<br><br>All uses of native methods, either thought P/Invoke, internal calls or with native code <br>
instead of IL, are type checkable. In case of bindings such as P/Invoke, the definition itself<br>is not verifiable as it's outside of the scope of the platform - but I guess BitC is on a similar<br>situation.<br> <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Let's look at a concrete example: what does CLR specify as the return<br>
type of the open() system call, and if it is not "int" then where and<br>
how is that return type defined?<br>
</blockquote><div> <br><br>The CLR decouples the C types from the binding definition. You either defines it to be<br>of a fixed width type or of a native size word. It's hard to reason about what the code do<br>outside of those two options. Most compilers today follow a very sane definition.<br>
<br>open could be defined as "int open (...)", and malloc could be "native int malloc (...)", for example.<br><br>Making a big effort to have c_int, c_long, c_ZZZ will shift the burden of bugs from the compiler to <br>
applications.<br><br></div></div>