Re: tostring userdata

[Andrew Gierth <andrew@...>]

>>>>> "Tom" == Tom Sutcliffe <tomsci@me.com> writes:

 Tom> I've tracked this down to the fact that the test - not the
 Tom> production code :) - was relying on the tostring representation of
 Tom> a full userdata 0xABCD being the same as the lightuserdata
 Tom> representation of the same pointer - they were both "userdata:
 Tom> 0x1234" on 5.3

er... no?

In 5.3, the tostring representation of something that's not a number,
string, boolean or nil and which has no __tostring metamethod is:

    lua_pushfstring(L, "%s: %p", kind, lua_topointer(L, idx));

where "kind" is the value of the __name metafield if it exists and is a
string, and is the luaL_typename of the original value otherwise.

I checked my own code and I definitely get "somename: 0xblah" when
printing full userdatas that have __name metafields.

 Tom> I couldn't find anywhere in the manual that this was mentioned -
 Tom> in particular __name is mentioned solely in the docs for
 Tom> luaL_newmetatable which states "The entry __name is used by some
 Tom> error-reporting functions" - and this change has broadened the
 Tom> scope of what __name is used for. I realise that the exact
 Tom> formatting of tostring is not defined in the API but previously
 Tom> changes like that of tostring(2.0) in 5.3 were at least mentioned
 Tom> in the "Changes in the Language" section - could we do the same
 Tom> here?

It's presumably not documented as a change because it didn't actually
change.

Most likely, what you're seeing is resulting from some other change that
is causing either the metatable to be (still?) set when it previously
wasn't, or __name to be set in the metatable when it previously wasn't.

-- 
Andrew.