llvm dev - Sep 2010 - [LLVMdev] IR type safety

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

On Tue, Sep 21, 2010 at 14:20, 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.
>
> Why create opaque types to avoid something that should be taken from
> granted (in a said "type-safe" representation)?
>
> [...]
>
> Am I being too picky?
>
I think you're just trying to do something that by design doesn't
work.  Your complaint seems to be that LLVM's type system doesn't give
you nominal type safety with transparent types, and you're right, it
doesn't, because transparent types work structurally.

If you want nominal type safety, then you need something else.  Two
possible options are name mangling the functions (as you mentioned C++
does), or use LLVM's opaque types, which work nominally.

LLVM's transparent types do, however, give you far more than C does.
Try linking these together:

    -- a.c --
    int foo(int);
    int bar(int a) { return a * foo(a); }

    -- b.c --
    int foo(char *p) { return puts(p); }

HTH,
~ Scott

P.S.  I don't think "transparent types" is an official LLVM term,
but
it seemed a reasonable opposite for "opaque types".

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
>

On 21 September 2010 23:00, Eugene Toder <eltoder at gmail.com>
wrote:
> 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).
Hi Eugene, Scott,

Point taken. The type system is safe, it's just not nominal. As Scott
said, if you need a nominal type system, you have to use something
else.

Thanks!

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm