What steps will reproduce the problem?
1. (\0)cvn ()cvn eq
2.
3. ==> yields true, should be: false
What is the expected output? What do you see instead?
Nametype objects should be able to contain nul (zero) characters
as part of the identifier.
Please use labels and text to provide additional information.
This is the last holdover of using the "C" string convention
(nul designated the end of the string) in the interpreter.
Everywhere else, counted (+optional offset) strings are used.
And the actual char*s are handled very carefully since
memory may move and invalidate the pointer after any new
allocation.
Returning the string identifier is already content-transparent
as the associated strings for the name integer code is in a
stack of objects, which is already generic.
But the string->integer conversion is done with ternary search
tree which uses a test for nul as the recursion bound in tree
creation, and the success criterion in tree search.
So, the search tree itself needs to be redesigned to carry
an extra count variable in the creation calls, and to designate
an end-of-string property for a tree node.
Original issue reported on code.google.com by luser.droog on 21 Mar 2014 at 5:52
Original issue reported on code.google.com by
luser.droogon 21 Mar 2014 at 5:52