You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to draw attention to the approach taken with the shortstring encoding. It was implemented by reusing the existing felt encoding.
As a basic example, a provided value "hello" will be encoded as 0x68656c6c6f, this I believe to not be contentious. The part where I believe there might be issues with is the encoding of numerical strings, the existing felt encoding treats both numbers and numerical strings as the same value and such behaviour might be undesirable/unexpected for the shortstring type. As an example "2" will be encoded as 0x2 while someone coming from a Cairo background will probably assume it to be encoded as 0x32.
Added context: This issue is a copy of the issue noted in this PR comment.
The text was updated successfully, but these errors were encountered:
I want to draw attention to the approach taken with the
shortstring
encoding. It was implemented by reusing the existingfelt
encoding.As a basic example, a provided value
"hello"
will be encoded as0x68656c6c6f
, this I believe to not be contentious. The part where I believe there might be issues with is the encoding of numerical strings, the existingfelt
encoding treats both numbers and numerical strings as the same value and such behaviour might be undesirable/unexpected for theshortstring
type. As an example"2"
will be encoded as0x2
while someone coming from a Cairo background will probably assume it to be encoded as0x32
.Added context: This issue is a copy of the issue noted in this PR comment.
The text was updated successfully, but these errors were encountered: