| Type | Bug | Status | tested | Date | 31-Jul-2009 09:09 |
|---|---|---|---|---|---|
| Version | alpha 76 | Category | Security | Submitted by | Sunanda |
| Platform | All | Severity | minor | Priority | normal |
| Summary | ALIAS breaks access to object values |
|---|---|
| Description |
o: make object! [a: 1 b: 2] *** R2 would not allow this next line as B is already in use. R3 allows it, with odd consequences: alias 'a "b" >> o: make object! [a: 1 b: 2] == make object! [ a: 1 b: 2 ] alias 'a "b" == b o ;; still looks okay == make object! [ a: 1 b: 2 ] o/a == 1 o/b ;; But: == 1 So both values are 1. But: *** resolve o o == make object! [ a: 2 b: 2 ] So maybe both are 2. But: *** Maybe B does not even exist: > o2: make object! [a: 99 b: 99] = make object! [ a: 99 ;; B gone! ] **** Or perhaps I've stumbled across a quantum variable: 1 or 2 or unset! depending on how it is observed :-) |
| Example code |
| Assigned to | n/a | Fixed in | alpha 111 | Last Update | 26-Feb-2011 01:13 |
|---|
| Comments | |
|---|---|
|
(0001444)
BrianH 31-Jul-2009 17:36 |
Unfortunately, you have stumbled on intended behavior: Object access is supposed to break in that case, in that way. It's a side effect of allowing ALIAS 'a 'b (see #341).
When a word is loaded it is (usually) bound to a context, and contexts are just objects. This means that accesses to 'b in that context are supposed to redirect to 'a, just like all future references to 'b in other contexts. The trick is that the translation is done at word! creation time. Aliasing is thus inherently a break in word dereferencing. So let's go through your example: >> o: make object! [a: 1 b: 2] An object with two value slots is created. The first is associated with the word 'a, the second with 'b. >> alias 'a "b" >> o == make object! [ a: 1 b: 2 ] The object o is displayed as a list of value slots, as pairs of the word and value associated with that value slot. This doesn't affect the accessibility of the values through IN or path notation, but what is shown does reflect what you will see with WORDS-OF, VALUES-OF and BODY-OF. >> o/a == 1 Path access to the first value slot, referenced through 'a. >> o/b == 1 Path access to the first value slot, referenced through 'a again (by way of its 'b alias). >> resolve o o == make object! [ a: 2 b: 2 ] (I'm guessing here) For each slot on the source object, the value in the slot is getting propagated to the value slot of the associated word in the target object. In both cases, that association leads to 'a because of the alias. However, because of a bug in RESOLVE that you have discovered, the associated value slot in the target is being reassigned even though it already has a set value. I'll make a ticket about that. >> o2: make object! [a: 99 b: 99] == make object! [ a: 99 ;; B gone! ] This is probably the result of cleanup code in MAKE object!. More interesting is this: >> o2: make o [a: 99] == make object! [ a: 1 b: 99 ] This might be related to bug #1163, but should have a ticket for it too. So this ticket should be dismissed as "not a bug", since breaking object access is the whole purpose of ALIAS. However, there are bugs in RESOLVE and MAKE object! that need tickets. |
|
(0001445)
BrianH 31-Jul-2009 18:08 |
Weird - I can't get the RESOLVE bug above to happen. Here is what I get:
>> o: context [a: 1 b: 2] == make object! [ a: 1 b: 2 ] >> alias 'a "b" == b >> resolve o o == make object! [ a: 1 b: 2 ] >> o == make object! [ a: 1 b: 2 ] ; Just in case it's a path bug >> o/a == 1 >> o/b == 1 >> resolve o o == make object! [ a: 1 b: 2 ] ; Nope, still works properly. Now I get that behavior from RESOLVE/all, but that is to be expected (not a bug): >> resolve/all o o == make object! [ a: 2 b: 2 ] Looks like I don't have to make the RESOLVE ticket after all. As for your MAKE object! aliased fields disappearing bug, I can't replicate that either. I always get the second slot updating behavior I showed above (see #1165). Which version of R3 are you testing with, on which platform? For alpha 76 on Windows I can't replicate the behavior you describe. |
|
(0001446)
Sunanda 31-Jul-2009 20:14 |
Sorry about the RESOLVE part -- it does not seem to be a bug on retesting....At least, I cannot recreate it now.
Not sure about your reasoning re ALIAS. If it breaks access to previously defined objects, that looks to me like a serious side-effect that could lead to hours of debugging. I'd prefer the R2 behavior: not allow ALIAS 'a "B" if B is already in existence. For example: alias 'state 'version ;; me just changing some user-space words 0 / 0 ;; later a crash ;; Now WHY? is broken: why? ** Script error: invalid argument: last-error ** Where: any all why? ** Near: any [:err system/state/last-error] err/type |
|
(0001558)
BrianH 21-Aug-2009 20:22 |
With the fixing of #341 in alpha 79, this ticket is back in play, and a security issue.
Note: It only affects aliases where the words differ in spelling, not in case. |
|
(0003070)
BrianH 31-Jan-2011 06:17 |
The ALIAS function has been removed in alpha 111. See #1835 for details. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 26-Feb-2011 01:13 | BrianH | Status | Modified | built => tested |
| 31-Jan-2011 06:18 | BrianH | Comment : 0003070 | Modified | - |
| 31-Jan-2011 06:17 | BrianH | Comment : 0003070 | Added | - |
| 31-Jan-2011 06:17 | BrianH | Status | Modified | reviewed => built |
| 31-Jan-2011 06:17 | BrianH | Fixedin | Modified | => alpha 111 |
| 21-Aug-2009 20:22 | BrianH | Comment : 0001558 | Added | - |
| 21-Aug-2009 20:17 | BrianH | Status | Modified | dismissed => reviewed |
| 21-Aug-2009 20:17 | BrianH | Severity | Modified | not a bug => minor |
| 21-Aug-2009 20:17 | BrianH | Category | Modified | Native => Security |
| 31-Jul-2009 20:37 | sunanda | Comment : 0001446 | Modified | - |
| 31-Jul-2009 20:14 | sunanda | Comment : 0001446 | Added | - |
| 31-Jul-2009 19:02 | BrianH | Comment : 0001445 | Modified | - |
| 31-Jul-2009 18:18 | BrianH | Comment : 0001445 | Modified | - |
| 31-Jul-2009 18:12 | BrianH | Comment : 0001445 | Modified | - |
| 31-Jul-2009 18:08 | BrianH | Comment : 0001445 | Added | - |
| 31-Jul-2009 17:36 | BrianH | Comment : 0001444 | Added | - |
| 31-Jul-2009 16:39 | BrianH | Status | Modified | submitted => dismissed |
| 31-Jul-2009 16:39 | BrianH | Severity | Modified | minor => not a bug |
| 31-Jul-2009 16:39 | BrianH | Description | Modified | - |
| 31-Jul-2009 09:09 | sunanda | Ticket | Added | - |