[LLVMdev] IR type safety

[Renato Golin]

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