Re: TypeInfo madness
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
Re: TypeInfo madness
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.
Re: TypeInfo madness
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.
Re: TypeInfo madness
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
Re: TypeInfo madness
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.
Re: TypeInfo madness
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
Re: TypeInfo madness
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?
Re: TypeInfo madness
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.
TypeInfo madness
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.
