In D (tested with D 2.070), one is allowed to modify TypeInfo returned by typeid().

Here is an example how this "feature" can be used maliciously.

	class A{
	}
	class C : A{
		int a = 1234;
	}
	class B : A{
		float b;
	}

	@safe void main() {
		import std.stdio;
		C c = new C;
		A a = cast(A)c;
		auto y = typeid(c);

		B b = new B;
		y.base = typeid(b);

		b = cast(B)a;
		assert(b !is null);
		writeln(b.b);
	}

With a successful dynamic cast, it should be safe to assume the data in the result object is well formed (enforced, for example, by invariants). However, the ability to modify a TypeInfo object will give the attacker a chance to pass crafted data to a function.

It is just a mistake that TypeInfo isn't immutable, in my opinion.

...though changing it would be a breaking change, I think it would make sense to do it.

On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>
> ...though changing it would be a breaking change, I think it would make sense to do it.

Is there really anything relies on TypeInfo being mutable?

On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:
> On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
>> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>>
>> ...though changing it would be a breaking change, I think it would make sense to do it.
>
> Is there really anything relies on TypeInfo being mutable?

LDC produces a crashing program when you change TypeInfo.name:
https://github.com/ldc-developers/ldc/issues/1337

On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote:
> On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:
>> On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
>>> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>>>
>>> ...though changing it would be a breaking change, I think it would make sense to do it.
>>
>> Is there really anything relies on TypeInfo being mutable?
>
> LDC produces a crashing program when you change TypeInfo.name:
> https://github.com/ldc-developers/ldc/issues/1337

This is because LDC put the TypeInfo struct in .rodata! Which is great. Further prove the point that no one is modifying TypeInfo.

On 3/7/16 1:33 PM, Yuxuan Shui wrote:
> On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote:
>> On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:
>>> On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
>>>> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>>>>
>>>> ...though changing it would be a breaking change, I think it would
>>>> make sense to do it.
>>>
>>> Is there really anything relies on TypeInfo being mutable?
>>
>> LDC produces a crashing program when you change TypeInfo.name:
>> https://github.com/ldc-developers/ldc/issues/1337
>
> This is because LDC put the TypeInfo struct in .rodata! Which is great.
> Further prove the point that no one is modifying TypeInfo.

Great evidence. Guess we should make everything immutable then. -- Andrei

On 3/8/16 1:38 PM, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/7/16 1:33 PM, Yuxuan Shui wrote:
>> On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote:
>>> On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:
>>>> On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
>>>>> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>>>>>
>>>>> ...though changing it would be a breaking change, I think it would
>>>>> make sense to do it.
>>>>
>>>> Is there really anything relies on TypeInfo being mutable?
>>>
>>> LDC produces a crashing program when you change TypeInfo.name:
>>> https://github.com/ldc-developers/ldc/issues/1337
>>
>> This is because LDC put the TypeInfo struct in .rodata! Which is great.
>> Further prove the point that no one is modifying TypeInfo.
>
> Great evidence. Guess we should make everything immutable then. -- Andrei

The fun part is going to be all the ripple effect changes required to api's to pass them around as const.  Those result in mangling changes and thus is a reasonably massive amount of low level ABI churn.

On Tuesday, 8 March 2016 at 21:44:28 UTC, Brad Roberts wrote:
> The fun part is going to be all the ripple effect changes required to api's to pass them around as const.  Those result in mangling changes and thus is a reasonably massive amount of low level ABI churn.

Perhaps we can make the data private with only public, final getter properties for it, to const data.

The .initializer property already returns const, so making m_init const shouldn't change anything. name is already string, so its contents are immutable.

vtbl and destuctor are void*, so they need to be casted anyway. I don't think const will break anything there.

Biggest worry I see is interfaces.... but I'm pretty sure again little should change. We can keep the outer type the same while just changing the member variables to minimize outside changes.

On Tuesday, 8 March 2016 at 21:38:58 UTC, Andrei Alexandrescu wrote:
> On 3/7/16 1:33 PM, Yuxuan Shui wrote:
>> On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote:
>>> On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:
>>>> On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
>>>>> It is just a mistake that TypeInfo isn't immutable, in my opinion.
>>>>>
>>>>> ...though changing it would be a breaking change, I think it would
>>>>> make sense to do it.
>>>>
>>>> Is there really anything relies on TypeInfo being mutable?
>>>
>>> LDC produces a crashing program when you change TypeInfo.name:
>>> https://github.com/ldc-developers/ldc/issues/1337
>>
>> This is because LDC put the TypeInfo struct in .rodata! Which is great.
>> Further prove the point that no one is modifying TypeInfo.
>
> Great evidence. Guess we should make everything immutable then.

This code relies on it being immutable:
    synchronized(typeid(Foo)) { ... }

People are using that, and their programs crash with LDC [1] [2].

For now, I think we will have to make TypeInfo mutable in LDC [3], until there is a definite decision on this.

[1] https://github.com/ldc-developers/ldc/issues/1377
[2] https://github.com/ldc-developers/ldc/issues/1358
[3] https://github.com/ldc-developers/ldc/pull/1380