[LLVMdev] IR type safety

Eugene Toder eltoder at gmail.com
Tue Sep 21 15:00:55 PDT 2010


This is a nominative vs. structural type system issue. You assume the
type system to be nominative, while LLVM uses a structural one. In
this type system Foo and Bar is the same type. There are various pros
and cons for both systems. For LLVM it seems appropriate to use
structural typing as it only uses types to calculate sizes, offsets
and alignments.

Btw arguably this is not a type safety problem -- either way the code
is "safe" since you can't access a value using incompatible view (e.g.
pointer as double).

Eugene

On Tue, Sep 21, 2010 at 10:20 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote:
>> Type names don't have meaning.  If you want this not to happen, you
>> can generate a different opaque type for each type in your language to
>> prevent merging.
>
> Hi Andrew,
>
> Why create opaque types to avoid something that should be taken from
> granted (in a said "type-safe" representation)?
>
> I know it simplifies garbage collecting, but the GC could have a
> different view of the symbol table to achieve that (if that's
> feasible).
>
> Maybe I'm just underestimating the GC problem, or there could be an
> even stronger reason behind it, I don't know...
>
> Just tried this example in Clang:
>
> -- a.cpp --
> struct Foo {
>        int a; int b;
> };
>
> int add(struct Foo f);
>
> int main() {
>        struct Foo f = { 42, 10 };
>        return add(f);
> }
> ----
>
> -- b.cpp --
> struct Bar {
>        int c; int d;
> };
>
> int add(struct Bar b) { return b.c - b.d; }
> ----
>
> In C++, with name mangling, you get a symbol error: Safe. In C, that
> compiles and return 32 (as expected): Safe again.
>
> So, assuming all languages conform to the C standard regarding
> structures, the IR is correct. In any other case, it's not.
>
> Am I being too picky?
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list