There is no need for this “priming” process, as others have noted. The author seems to be using this as a way to pass state from C code into Lua (via global variables), but this is pretty crude; you are better off passing arguments on the stack as I previously outlined. Of course, if the Lua code expects a global “foo” and there isn’t one, yes it will get nil when it tries to read it, but the fix there is probably not to expect a “foo” global in the first place :)
Think about the stand-alone “lua” command that you can use to run any Lua script from the command line. This utility is just a very thin wrapper that creates a Lua state (and loads the standard libraries) reads the Lua script from a file, compiles it using lua_load(), and then calls it using lua_call(). (I’m simplifying a lot here, technically it uses slightly different APIs, but the basic model is the same).