global << operator Runtime Errors

ID:85024
 
Nov 2 2009, 5:18 pm (Edited on Nov 3 2009, 4:57 am)
BYOND Version:454
Operating System:Windows 7 64-bit
Web Browser:Firefox 3.5.4
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
I've been studying more about DMB files through experimentation and happen to find the cause of some of the runtime errors involving a global without providing a variable name. When you use it in the form of global << while trying to attempt output (no global variable, but global by itself), it will not be able to what I think is the stack properly.

world << global (Just an example) on the other hand what I think will load the wrong value into the stack, which can cause a misread. This was while I was still researching about DMB files.

Numbered Steps to Reproduce Problem:
Look at two sets of source code below

Code Snippet (if applicable) to Reproduce Problem:
mob
    Login()
        ..()
        world << global // 33 00 E5 FF 33 00 03 00 (0300 was meant for normal output operation)


mob
    Login()
        ..()
        global << world // 33 00 33 00 E5 FF 03 00 (Loads the load operation from what I can tell instead of world.  Of course from what I have right now, there are two forms of the output operator due to the [] macro included in strings.


Expected Results:
Compilation error normally for not including any variable.

Actual Results:
Compiles anyway, though with runtime errors when such procs are run.

Does the problem occur:
Every time? Or how often? Everytime
In other games? N/A
In other user accounts? N/A
On other computers? N/A

When does the problem NOT occur? As long you include a variable or proc name (though this applies to global variables from my testing).

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) N/A

Workarounds:
Best thing to do is not output to and from global unless you define a global variable. I assume this problem may require digging through possibly ancient code I heard about to at least block such future occurrences.
</<></<>
Jan 18 2016, 9:57 am
Tested in 509.1319 and 510.1322.

Descriptive Problem Summary:
'global' can be used seemingly like any other variable, but generally runtimes with weird 'cannot read null.[something]' runtimes on execution

Numbered Steps to Reproduce Problem:
1. Use 'global' for something
2. Runtime

Code Snippet (if applicable) to Reproduce Problem:
/world/New()
    for(var/P in typesof(/proc))
        call(P)()
    del(src)

/proc/testA()
    for(var/v in global) // Cannot read null.area
        continue

/proc/testB()
    var/x = global // Cannot read null.y

/proc/testC()
    global() // Cannot read null.icon

/proc/testD()
    global = null // Cannot modify null..

/proc/testE()
    global += 1 // Cannot read null.

/proc/testF()
    .(global) // Cannot read null.opacity

/proc/testG()
    global["foo"] // Cannot read null.view

/proc/testH()
    var/x = global + global // Cannot read null.x

/proc/testI()
    return global // Cannot read null.Northwest

/proc/testJ()
    for(global in list()) // Cannot modify null.Northeast
        continue

/proc/testK()
    if(global in list()) // Cannot read null.screen_loc
        return

/proc/testL()
    new global() // Cannot read null.Exit

/proc/testM()
    md5(global) // Cannot read null.Error

/proc/testN()
    istype(global, /datum) // Cannot read null.view

/proc/testO()
    istype(null, global) // Cannot read null.cache_lifespan

/proc/testP()
    istype(global, global) // Cannot read null.x

/proc/testQ()
    var/x = "[global]" // Cannot read null.Enter

/proc/testR()
    ispath(null, global) // Cannot read null./matrix

/proc/testS()
    world.Del(global) // Cannot read null.text

/proc/testT()
    testT(global) // Cannot read null.density

/proc/testU()
    ..(global) // Cannot read null.visibility

/proc/testV()
    throw(global) // Cannot read null.AREA_LAYER


Expected Results:
Code above would not compile, or would give meaningful results in the case of testA (and possibly testB/testF/testG)

Actual Results:
Code above compiles, all of testA through testV runtime on the commented line with the commented message.

Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? Untested
On other computers? Untested

When does the problem NOT occur? Unknown

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown

Workarounds: Don't use global like this?

Jan 20 2016, 12:41 pm
In response to GinjaNinja32
Man if only testA was a legit thing you can do...
Jan 20 2016, 7:57 pm
In response to GinjaNinja32
 
/world/New()
    testA()
    testB()
    testC()
    testD()
    testE()
    testF()
    testG()

You are missing testH()
Jan 21 2016, 12:36 am
In response to GinjaNinja32
Yep, must have missed that. G/H were added after posting, I did a bit more testing.
Jan 21 2016, 6:57 pm
In response to GinjaNinja32
2 Questions, Did you get it to work yet, and what is the purpose of the function?
Jan 21 2016, 11:32 pm
In response to Dragonpearl123
I'm not sure what you mean?
Jan 22 2016, 3:51 pm
In response to GinjaNinja32
What I am trying to say is, what is the purpose of the global A-H and can you find an exploit around it.
Jan 22 2016, 7:30 pm
In response to Dragonpearl123
Each check runtimes. Putting each in its own proc lets them all run without crashing each other. I'm not sure what you mean by "can you find an exploit around it".
Jan 23 2016, 12:31 pm
In response to GinjaNinja32
Every problem has more than one solution on byond. Just find another way to check runtimes.
Jan 23 2016, 12:43 pm
In response to Dragonpearl123
I don't think Ginja here was trying to find a practical use for it, he just encountered it and decided it'd be worth reporting, because why not?
Feb 1 2016, 6:44 pm
In response to GinjaNinja32
So basically, the compiler should be failing the build, but it keeps on trucking somehow.

Each time it encounters 'global' without a variable after it, it builds in the op code 0x33 (load reference), but doesn't finish the code by saying what it needs to load.

testB, for instance, starts of with 0x33, and then is immediately followed by 0x34 (store reference). The 0x33 code thinks that the 0x34 is the variable it is supposed to be loading. Coincidentally, 0x34 is also the string ID for "y". This is happening in each case, with different operations being interpreted as different strings each time.
Mar 31 2016, 7:37 pm
In response to GinjaNinja32
I know my post is a tad bit late, but I remember encountering a very similar bug involved with global. In fact, there are plenty of crazy bugs involving global.

Here is my old report in reference to the '<<' operator: http://www.byond.com/forum/?post=85024&hl=Global

Due to the nature of this bug; it is very unlikely it will get fixed. Especially, when this bug happens during the compilation process; resulting in invalid code that leads to many runtime errors.
Aug 9 2018, 1:32 pm
(Filed under Dream Maker because Lummox has said in the past that this should not compile, but whatever nonsense code DM is spitting out also has a clear effect on DD)

Descriptive Problem Summary:
In nearly all cases, the compiler will not error if the "global" keyword is treated as a var. If Dream Daemon executes any code where you do so (other than variable access, of course), a runtime will occur. This runtime will almost always be of the form "Cannot read null.[something]" where [something] is the name of a seemingly random built-in var, const, or proc.

Numbered Steps to Reproduce Problem:
1. Insert any of the below lines of code somewhere they will be executed, such as in /world/New()

Code Snippet (if applicable) to Reproduce Problem:
Each line is a separate case, to be clear. 
var/a = global //Runtime is the same regardless of var name
throw global
global++ //All operate-and-assign operators have the same runtime when global is the LHS
global + 1 //Same for all mathematical operators where global is first, and all commutative operators regardless of order
1 - global //Non-commutative ones vary when global is the second, though. This is only one example.
locate(global)
var/a = "[global]" //Same regardless of anything else in the string
world.log << "[global]" //Also the same regardless of anything else in the string
world.log << global
var/b = global?.a //Where a is a valid global var. Also the name of b doesn't matter.
world.log << global?.a //Where a is a valid global var.

And countless others, of course. This is just a sampling of them that demonstrates that context matters, and that the "something" in null.something can at least be the names of built-in global consts (such as UP), member variables (y), member procs (Enter), and even seemingly strings with built-in significance (plural), and that at least two other kinds of runtimes can happen.

Expected Results:
Compile failure

Actual Results:
(Each runtime corresponds to one of the above lines of code, in the same order.) 
Cannot read null.y
Cannot read null.UP
Cannot read null. //That's not a typo, it does just say null.
Cannot read null.mob
Cannot read null.statpanel
Cannot read null.plural
Cannot read null.Enter
BYOND Error: bad instruction: 417
//This one actually doesn't runtime for some reason. Thought it was interesting to include anyway.
Cannot read null.TURF_LAYER
BUG: Crashing due to an illegal operation!


When does the problem NOT occur?
When you don't treat "global" as a var except for global.whatever

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Only tested in 512.1427, but according to Lummox, "it's almost certainly not new"

Workarounds:
This is nonsense code which shouldn't compile. Don't write nonsense code, I guess.
Sep 8 2018, 4:41 am
In response to Exxion
Sep 8 2018, 11:33 am
In response to Exxion
Well I guess that means the characterization as "not new" was correct
Jesus
Sep 8 2018, 4:13 pm
In response to Exxion