[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376 klickverbot changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #3 from klickverbot 2011-07-24 16:29:15 PDT --- I can confirm that my problems I reported on the NG seem to be caused by throwing exceptions as well. As mentioned there, one can run �set disable-aslr off� in GDB to debug with ASLR enabled (otherwise, the crashes don't happen for me). I have not had time to trace down what exactly is going on, but the issue seems to be related somehow to *throwing* exceptions, not catching them (I might have jumped to the wrong conclusions based off debugger output here, though). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 --- Comment #4 from Vladimir Panteleev 2011-07-24 16:22:56 PDT --- OK, I agree completely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 --- Comment #3 from Jonathan M Davis 2011-07-24 16:20:40 PDT --- It depends on what you mean by "safe." When we talk about safe, we usually mean "memory safe," and this conversion is perfectly safe as far as memory goes. And even with regards to other types of safe, whether converting -1 to uint could still be safe. There are plenty of cases where people do that _on purpose_. Obviously, if you're looking to ensure that negative values aren't converted to unsigned ones, this isn't safe. So, it depends entirely on what you're trying to do. And generally speaking, safe refers to memory safety, and this _is_ safe in that sense. I don't think that we ever actually use the term safe to refer to making sure that a negative value isn't converted to an unsigned value or that an unsigned value which is outside of the range of a signed value isn't converted to a signed one. Now, std.conv _will_ throw a ConvOverflowException error in cases where you do something like convert an int to a byte when it won't fit, so there's a definite argument that converting from -1 to uint with std.conv.to should throw. But the language itself considers int and uint interchangeable as far as conversions go. No cast is even necessary (while it _would_ be when converting from int to byte). So, whether to!uint(-1) should throw or not is up for debate. It's completely memory safe, and the language itself has no problem with the conversion and requires no cast. But there are plenty of people who would want it to catch such an overflow just like it would when converting from an int to a byte. So, this is a perfectly legitimate enhancement request, and we may very well want to change how it acts in this case, but it's not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377
Jonathan M Davis changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
Platform|Other |All
OS/Version|Windows |All
Severity|normal |enhancement
--- Comment #1 from Jonathan M Davis 2011-07-24 16:06:40
PDT ---
That's debatable. There _are_ cases where you wouldn't want a negative value to
be converted to an unsigned integral value, but there are also cases where you
_would_ want it to happen. For better or worse, unsigned integral values
implicitly convert to signed integral values of the same size. It ends up using
the most basic version of std.conv.to
T toImpl(T, S)(S value)
if (isImplicitlyConvertible!(S, T))
{
return value;
}
This isn't a bug. It _might_ be a change that we want to make, but it's not a
bug. This is the expected behavior. You wouldn't get any more of an error if
you just assigned to a uint from an int directly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6377] std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377 --- Comment #2 from Vladimir Panteleev 2011-07-24 16:08:26 PDT --- I thought the whole point of std.conv.to for integer to integer conversions is to make them safe, and make sure that the value - as interpreted from the source type - can be correctly represented in the destination type. If this isn't the point of std.conv.to, it should be explicitly documented what its goals are, and there should probably be something else in the standard library to facilitate safe integer conversions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6377] New: std.conv.to should check range when changing signedness
http://d.puremagic.com/issues/show_bug.cgi?id=6377
Summary: std.conv.to should check range when changing
signedness
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir Panteleev 2011-07-24
15:54:35 PDT ---
import std.conv, std.exception;
void main()
{
int b = -1;
assertThrown!ConvException(to!uint(b));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6376] Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376 --- Comment #1 from kenn...@gmail.com 2011-07-24 15:33:29 PDT --- See also discussion in http://thread.gmane.org/gmane.comp.lang.d.general/61384. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6376] New: Throwing exception or assertion failure causes segfault or memory error due to ASLR on Mac OS X 10.7
http://d.puremagic.com/issues/show_bug.cgi?id=6376
Summary: Throwing exception or assertion failure causes
segfault or memory error due to ASLR on Mac OS X 10.7
Product: D
Version: D2
Platform: x86
OS/Version: Mac OS X
Status: NEW
Keywords: EH, wrong-code
Severity: blocker
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-07-24 15:29:07 PDT ---
Test case 1
---
void main() {
assert(0);
}
---
Running this program on 10.7 causes
Bus error: 10
while the expected output should be something like
core.exception.AssertError@y(2): Assertion failure
5 y 0x9265 onAssertError + 65
6 y 0x000126ca _d_assertm + 30
...
Test case 2
---
void main() {
throw new Exception("");
}
---
Running this program on 10.7 causes
y(96008) malloc: *** error for object 0x14b060: pointer being freed was not
allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
while the expected output should be something like
object.Exception@y.d(2):
5 y 0x2320 _Dmain + 80
6 y 0x00012dc7 extern (C) int
rt.dmain2.main(int, char**).void runMain() + 23
...
I suspect the stack-trace routine has some code depending on having no ASLR, so
I've marked it a druntime problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6374] [CTFE] Cannot subscript using pointer to array
http://d.puremagic.com/issues/show_bug.cgi?id=6374 --- Comment #1 from kenn...@gmail.com 2011-07-24 14:53:02 PDT --- Note that this prevents std.array.appender from being CTFE-able, because it contains the code: _data.arr.ptr[len] = cast(Unqual!T)item; // <-- error _data.arr = _data.arr.ptr[0 .. len + 1]; // (OK) Currently, this could be worked-around by swapping the two statements and use the standard indexing: _data.arr = _data.arr.ptr[0 .. len+1]; // OK _data.arr[len] = cast(Unqual!T)item;// now OK but I think the more proper solution is to fix this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6375] New: [CTFE] Segfault when using std.array.appender with an initial array
http://d.puremagic.com/issues/show_bug.cgi?id=6375
Summary: [CTFE] Segfault when using std.array.appender with an
initial array
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-07-24 14:41:19 PDT ---
Test case:
-
struct D6375 {
int[] arr;
}
A6375 a6375(int[] array) {
return A6375(array);
}
struct A6375 {
D6375* _data;
this(int[] arr) {
_data = new D6375;
_data.arr = arr;
}
int[] data() {
return _data.arr;
}
}
static assert({
int[] a = [ 1, 2 ];
auto app2 = a6375(a);
auto data = app2.data();
return true;
}());
-
Bus error: 10
-
This is essentially the trimmed down version of the unit test for
std.array.appender, running in CTFE. The segfault is due to
StructLiteralExp::getField in expression.c:
if (e->type->castMod(0) != type->castMod(0) && type->ty == Tsarray)
// e->type is NULL
Running e->semantic() once fixed the issue, but I'm not sure if this is the
best solution.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6374] New: [CTFE] Cannot subscript using pointer to array
http://d.puremagic.com/issues/show_bug.cgi?id=6374
Summary: [CTFE] Cannot subscript using pointer to array
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-07-24 14:05:05 PDT ---
Test case:
-
static assert({
int[] arr = [1];
arr.ptr[0] = 2; // <-- line 3
return arr[0];
}() == 2);
-
y.d(3): Error: cannot determine length of cast(int*)arr at compile time
y.d(5): Error: cannot evaluate delegate pure nothrow int()
{
int[] arr = [1];
(cast(int*)arr)[0u] = 2;
return arr[0u];
}
() at compile time
y.d(1): Error: static assert (delegate pure nothrow int()
{
int[] arr = [1];
(cast(int*)arr)[0u] = 2;
return arr[0u];
}
() == 2) is not evaluatable at compile time
-
Slicing is OK, though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #21 from Kenji Hara 2011-07-24 12:20:00 PDT
---
(In reply to comment #20)
> This too is valid D code:
>
> auto a = [1, 2,];
I didn't know that. Thank you.
In this case, TupleDeclaration syntax is similar to ParameterList.
void f(int i, string j){ ... }
(int i, string j) = tuple(1, "a");
auto (i, j) = tuple(1, "a");
But, 1 parameter function does not allow isolated comma.
void f(int i){ ... }
(int i) = tuple(1);
auto (i) = tuple(1);
//void f(int i,){ ... } // invalid
//(int i,) = tuple(1); // associatively invalid
//auto (i,) = tuple(1); // associatively invalid
How about you?
I didn't know following syntax is valid...
void f(int i, ){ }
(int i,) = tuple(1, "a"); // associatively valid
auto (i,) = tuple(1, "a"); // associatively valid
Hmm, it is hard achnowledgment to me, but it is valid syntax for consistency...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #20 from bearophile_h...@eml.cc 2011-07-24 12:01:55 PDT --- (In reply to comment #19) > In D, Isolated comma is almost invalid except enum declaration, I think. This too is valid D code: auto a = [1, 2,]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #19 from Kenji Hara 2011-07-24 11:43:28 PDT --- (In reply to comment #18) > Are you sure you want to use that syntax? Yes. The syntax is usuful for tuple expansion and non-auto binding: const (x, y) = tuple(10, 20); // x and y are now const It is more usuful for many element tuple: (const x, const y, const z, const v, const w, const m, const n) = ... ; // same as: // const (x, y, z, v, w, m, n) = ... ; > A syntax more similar to the Python one is: > > auto (x1,) = [10]; In D, Isolated comma is almost invalid except enum declaration, I think. D is not Python. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #18 from bearophile_h...@eml.cc 2011-07-24 11:14:57 PDT --- (In reply to comment #17) > > // 1-tuple expansion > auto (x1) = [10]; Are you sure you want to use that syntax? A syntax more similar to the Python one is: auto (x1,) = [10]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 177] Remove inheritance protection
http://d.puremagic.com/issues/show_bug.cgi?id=177 Stewart Gordon changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #7 from Stewart Gordon 2011-07-24 09:44:36 PDT --- I wish we had a REDUCED resolution, which takes an issue number in the same way as DUPLICATE. Meanwhile, for want of that *** This issue has been marked as a duplicate of issue 5299 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5299] Protected inheritance is semantically undefined.
http://d.puremagic.com/issues/show_bug.cgi?id=5299 Stewart Gordon changed: What|Removed |Added CC||ben...@tionex.de --- Comment #3 from Stewart Gordon 2011-07-24 09:44:36 PDT --- *** Issue 177 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5299] Protected inheritance is semantically undefined.
http://d.puremagic.com/issues/show_bug.cgi?id=5299 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #2 from Stewart Gordon 2011-07-24 09:38:50 PDT --- Looking at (In reply to comment #1) > Well, that's exceptionally weird. It compiles too. D doesn't > support any kind of inheritance but public. It seems like either > it's a hold-over which was never removed (assuming that D supported > private or protected inheritance in the past), According to the description and first comment on issue 177, private/protected inheritance once worked. But it doesn't work now (1.069, 2.054). But it never made sense to have the feature in D. > or it was intended to make porting C++ code easier. D was never intended to be source-compatible with C++, or even C. Consequently, such a tiny concession makes no sense at all, and even less sense considering the fundamental differences between C++ classes and D classes. > But it seems to me that allowing and then ignoring (as the compiler > presumably does) protection identifiers when inheriting classes is > not good behavior. The fact that the compiler allows it though > means that it's more than just a spec issue. Issue 177 is "Remove inheritance protection". Essentially that has been done, but by ignoring attempts to use it rather than making it illegal. So that issue has been reduced to this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3934] Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
--- Comment #24 from kenn...@gmail.com 2011-07-24 09:09:15 PDT ---
(In reply to comment #20)
> This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest
> to statically disallow it, as the other examples:
>
>
> class Foo {}
> class Bar : public Foo {}
> void main() {}
Bug 177, Bug 5299.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3934] Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
--- Comment #23 from Stewart Gordon 2011-07-24 07:54:03 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
>> (In reply to comment #20)
>>> class Foo {}
>>> class Bar : public Foo {}
>>> void main() {}
>>
>> There are no attributes as such in your example. And I don't see
>> anything that isn't meaningful. So what do you mean?
>
> I think bearophile is referring to the �public� protection attribute in the
> SuperClass. This is explicitly allowed by the grammar, but I don't know off
> hand if it actually has any effect in the current implementation, other than
> giving C++ programmers a wrong sense of coziness maybe. ;)
Therein lies my point - it isn't an attribute as such, and it isn't
meaningless. It means the same as in C++, though it doesn't make sense to have
the feature in D. But this point is covered by issue 177.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3934] Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
klickverbot changed:
What|Removed |Added
CC||c...@klickverbot.at
--- Comment #22 from klickverbot 2011-07-24 07:42:16 PDT
---
(In reply to comment #21)
> (In reply to comment #20)
> > class Foo {}
> > class Bar : public Foo {}
> > void main() {}
>
> There are no attributes as such in your example. And I don't see anything
> that
> isn't meaningful. So what do you mean?
I think bearophile is referring to the �public� protection attribute in the
SuperClass. This is explicitly allowed by the grammar, but I don't know off
hand if it actually has any effect in the current implementation, other than
giving C++ programmers a wrong sense of coziness maybe. ;)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #17 from Kenji Hara 2011-07-24 07:38:49 PDT --- (In reply to comment #16) > How does it behave for 0-tuples and 1-tuples? I think 1-element tuple expansion should be allowed. Now my patch's this support is incomplete. I'll improve it. // 1-tuple expansion auto (x1) = [10]; (auto x2) = tuple(10); (auto x3) = tuple(10)[0..1]; (int x4) = TypeTuple!(10); assert(x1 == 10); assert(x2 == 10); assert(x3 == 10); assert(x4 == 10); The 0-element tuple with TupleDeclaration should be error. Because they has no elements, so expansion cannot get value. //auto () = []; //(auto ) = tuple(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3934] Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
--- Comment #21 from Stewart Gordon 2011-07-24 07:38:37 PDT ---
(In reply to comment #20)
> This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest
> to statically disallow it, as the other examples:
>
> class Foo {}
> class Bar : public Foo {}
> void main() {}
There are no attributes as such in your example. And I don't see anything that
isn't meaningful. So what do you mean?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #16 from bearophile_h...@eml.cc 2011-07-24 07:24:53 PDT --- (In reply to comment #15) > I clean up syntax, and update patch. > https://github.com/9rnsr/dmd/compare/expandTuples...declarationTuple Thank you. How does it behave for: a[1] = [10]; auto (x, y) = a; How does it behave for 0-tuples and 1-tuples? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365
--- Comment #15 from Kenji Hara 2011-07-24 06:41:36 PDT
---
I found a conflict like follows:
(double, string) (i, j) = tuple(1.2, "a");
(var, func)(var, var) = tuple(1.2, "a");
So it is bad.
I clean up syntax, and update patch.
https://github.com/9rnsr/dmd/compare/expandTuples...declarationTuple
TupleDeclaration:
StorageClasses ( IdentifierList ) = Initializer ; // 1
( ParameterList ) = Initializer ; // 2-1
( StorageClass TupleTypeList ) = Initializer ; // 2-2
TupleTypeList:
TupleType
TupleType , TupleTypeList
TupleType:
StorageClasses BasicType Declarator
BasicType Declarator
StorageClasses Identifier
Identifier
// Example of 1
auto (i, j) = tuple(10, "a");
static assert(is(typeof(i) == int));
static assert(is(typeof(j) == string));
const (x, y) = TypeTuple!(1, 2);
static assert(is(typeof(x) == const(int)));
static assert(is(typeof(y) == const(int)));
// Example of 2-1
(int i, string j) = tuple(10, "a");
static assert(is(typeof(i) == int));
static assert(is(typeof(j) == string));
// Example of 2-2
(auto c, r) = TypeTuple!('c', "har");
static assert(is(typeof(c) == char));
static assert(is(typeof(r) == string));
(const x, auto y) = TypeTuple!(1, 2);
static assert(is(typeof(x) == const(int)));
static assert(is(typeof(y) == int));
(auto a1, const int[] a2) = TypeTuple!([1], [2,3]);
static assert(is(typeof(a1) == int[]));
static assert(is(typeof(a2) == const(int[])));
TupleTypeList is similar to ForeachTypeList.
http://d-programming-language.org/statement.html#ForeachStatement
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6373] New: More descriptive 'hidden by X is deprecated' error
http://d.puremagic.com/issues/show_bug.cgi?id=6373
Summary: More descriptive 'hidden by X is deprecated' error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-07-24 06:04:20 PDT ---
Wrong D2 code:
class Foo {
void method(int x) {}
void method(double x) {}
}
class Bar : public Foo { // line 5
override void method(int x) {}
}
void main() {
Foo f = new Bar();
f.method(1);
f.method(1.5);
}
DMD 2.054 gives the error:
test.d(5): Error: class test.Bar use of test.Foo.method(double x) hidden by Bar
is deprecated
While this program gives no errors:
class Foo {
void method(int x) {}
void method(double x) {}
}
class Bar : public Foo {
alias Foo.method method;
override void method(int x) {}
}
void main() {
Foo f = new Bar();
f.method(1);
f.method(1.5);
}
In the error message I suggest to add some reference to this usage of alias,
because in D.learn I've seen some D programmers blocked by this error message.
A possible message (also note the error line number, 6 instead of 5):
test.d(6): Error: class test.Bar use of test.Foo.method(double x) hidden by Bar
is deprecated. Use alias Foo.method method; if intended.
Or even, to be more clear:
test.d(6): Error: class test.Bar use of test.Foo.method(double x) hidden (not
overridden) by Bar is deprecated. Use alias Foo.method method; if intended.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3934] Some untidy attributes
http://d.puremagic.com/issues/show_bug.cgi?id=3934
--- Comment #20 from bearophile_h...@eml.cc 2011-07-24 05:51:32 PDT ---
This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest
to statically disallow it, as the other examples:
class Foo {}
class Bar : public Foo {}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6372] New: data loss due to possible bug in garbage collector
http://d.puremagic.com/issues/show_bug.cgi?id=6372 Summary: data loss due to possible bug in garbage collector Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: bughunt...@googlemail.com --- Comment #0 from Jelle Geerts 2011-07-24 04:02:17 PDT --- Created an attachment (id=1011) testcase for possible bug in gcx.d It seems that during reallocation, the garbage collector does not always copy enough bytes to the new block should a new block be allocated. The first reallocation seems ok, but the next reallocation is where things go awry. I've added a comment to the testcase which I've attached. It explains the issue in a bit more detail. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
