Thread overview | |||||
---|---|---|---|---|---|
|
January 29, 2009 [Issue 2632] New: Setting length on invalid arrays causes assertion failure with a debug runtime | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=2632 Summary: Setting length on invalid arrays causes assertion failure with a debug runtime Product: D Version: 1.039 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: bugzilla@digitalmars.com ReportedBy: matti.niemenmaa+dbugzilla@iki.fi Both of the below test cases work unless compiled against a debug runtime. Test case 1: void main() { int[] a = (cast(int*)null)[0..1]; a.length = 1; assert (a.length == 1); assert (a[0] == 0); } Test case 2: union Union { int i; ubyte[] a; } void main() { Union u; u.i = 10; u.a.length = 1; assert (u.a.length == 1); assert (u.a[0] == 1); } The problematic assertion is assert(!p.length || p.data). It occurs in three functions: - _d_delarray - _d_arraysetlengthT - _d_arraysetlengthiT The second one of the above is triggered by the given test cases. It'd be easy to come up with ones that trigger the other two as well. This behaviour doesn't seem to be specified, so I'm not completely sure whether this should be fixed or not. I have two arguments in favour of removing the assertions: 1. They're only sanity checks: they don't actually matter for behaviour. Code which trips the asserts on a debug runtime runs fine on a release runtime. Nothing actually expects the assertions to succeed. 2. Code which relies on such behaviour actually exists: test case 2 was reduced from tango.text.Regex. In Phobos, the functions are in phobos/internal/gc/gc.d; in Tango, they can be found in tango/lib/compiler/{dmd,gdc}/lifetime.d; in LDC, they're in runtime/internal/lifetime.d. This issue affects all of them. -- |
February 08, 2009 [Issue 2632] Setting length on invalid arrays causes assertion failure with a debug runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=2632 matti.niemenmaa+dbugzilla@iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Phobos |www.digitalmars.com Keywords| |spec ------- Comment #1 from matti.niemenmaa+dbugzilla@iki.fi 2009-02-08 10:33 ------- I'm moving this to www.digitalmars.com and adding the 'spec' keyword since it seems that there's absolutely nothing written down about this possibility. I believe this needs to be clarified. If the answer indicates that Phobos should change, I'll file a separate bug for that. The basic issue is, what operations, if any, are allowed on dynamic arrays which are in an invalid state, i.e. have a nonzero length but a null pointer? (I suppose the converse—nonnull pointer but zero length—is fine.) "Implementation defined" is a fine answer as long as it's actually specified. Associative arrays don't have this problem since their ABI says that they're just a pointer to an implementation defined type. -- |
January 23, 2012 [Issue 2632] Setting length on invalid arrays causes assertion failure with a debug runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=2632 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla@digitalmars.com Resolution| |INVALID --- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2012-01-22 22:11:06 PST --- I think both cases are clearly undefined behavior. The first uses a cast to bypass checks in order to create an array of elements that don't exist, the second uses a union to achieve the same. I don't think the spec needs to be changed to reflect that using unions to manipulate things under the hood, and using forcible casts, mean you're on your own. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation