Improve output of userdata, handling__tostring and NULL#45
Open
hishamhm wants to merge 2 commits intokikito:masterfrom
Open
Improve output of userdata, handling__tostring and NULL#45hishamhm wants to merge 2 commits intokikito:masterfrom
__tostring and NULL#45hishamhm wants to merge 2 commits intokikito:masterfrom
Conversation
When interpreting userdata values using 'inspect', the numeric identifiers are useful to match identify of pointers (comparing the low counters like `<userdata 3> is easier than reading long pointers like `userdata: 0x749abc39efa29`). However, the `NULL` pointer is enough of a special case that it is important to know when one of those numbered pointers happens to be `NULL`. When one is dealing with things like JSON parsers, where the only usual userdata is `cjson.null`, one gets accostumed over time to interpret `<userdata 1>` to mean `NULL`. This is not obvious, however, and a seasoned user will trip up the day another userdata is used in the same table and `NULL` is now `<userdata 2>`. Adding a test for this would require compiling and loading a C extension.
2 similar comments
C3pa
reviewed
Dec 27, 2024
| local toStringResult = mt and getToStringResultSafely(v, mt) | ||
| if toStringResult then | ||
| self:puts('<userdata ', self:getId(v), '>') | ||
| self:puts(' -- ', escape(toStringResult)) |
There was a problem hiding this comment.
I tried this. Looks a bit strange when this is printed as a table key. An example:
[<userdata 1> -- light_de_candle_14_64] = <userdata 2> -- NiNode:Light_Com_Candle_03,
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR includes 2 commits:
The first one includes evaluation of
__tostringfor userdata values. This should be safe because__tostringof userdata is unlikely to recurse intoinspect. A test is included.The second one adds a special case for NULL userdata.
When interpreting userdata values using 'inspect', the numeric identifiers
are useful to match identify of pointers (comparing the low counters
like
<userdata 3> is easier than reading long pointers likeuserdata: 0x749abc39efa29`).However, the
NULLpointer is enough of a special case that it isimportant to know when one of those numbered pointers happens to
be
NULL. When one is dealing with things like JSON parsers, wherethe only usual userdata is
cjson.null, one gets accostumed overtime to interpret
<userdata 1>to meanNULL. This is not obvious,however, and a seasoned user will trip up the day another userdata
is used in the same table and
NULLis now<userdata 2>.Adding a test for this would require compiling and loading a C extension, such as
lua-cjson. I can do so if desired.