ID:2662996
 
Resolved
sha1() with a constant string compiled incorrectly.
BYOND Version:513
Operating System:Linux
Web Browser:Firefox 85.0
Applies to:Dream Maker
Status: Resolved (514.1550)

This issue has been resolved.
Descriptive Problem Summary: sha1() compiles incorrectly when given a constant argument.

Numbered Steps to Reproduce Problem: Run code below.

Code Snippet (if applicable) to Reproduce Problem:
/world/New()
var/s = "a"

. = sha1(s)
world.log << "sha1(s) = '[.]'"

. = sha1("a")
world.log << "sha1(\"a\") = '[.]'"


Expected Results:
sha1(s) = '86f7e437faa5a7fce15d1ddcb9eaeaea377667b8'
sha1("a") = '86f7e437faa5a7fce15d1ddcb9eaeaea377667b8'

Actual Results:
sha1(s) = '86f7e437faa5a7fce15d1ddcb9eaeaea377667b8'
sha1("a") = '÷ä7ú¥§üá]&#1849;êêê7vg¸'


As far as I can tell, it's putting the raw bytes through Windows-1252-to-UTF-8 conversion, but keeping anything that happens to be valid UTF-8; the above gibberish is:
INPUT   HOW         OUTPUT
86 Convert U+86 START OF SELECTED AREA (non-printing)
f7 Convert ÷ U+F7 DIVISION SIGN
e4 Convert ä U+E4 LATIN SMALL LETTER A WITH DIAERESIS
37 As-is 7 U+37 DIGIT SEVEN
[...]
5d As-is ] U+5D RIGHT SQUARE BRACKET
1d As-is U+1D INFORMATION SEPARATOR THREE (non-printing)
dc b9 As-is (!) U+0739 SYRIAC DOTTED ZLAMA ANGULAR
ea Convert ê U+EA LATIN SMALL LETTER E WITH CIRCUMFLEX
ea Convert ê U+EA LATIN SMALL LETTER E WITH CIRCUMFLEX
ea Convert ê U+EA LATIN SMALL LETTER E WITH CIRCUMFLEX
[...]


Sometimes there seems to be an extra '!' at the end of the string - one tested machine shows this, the other doesn't. I'm not sure why this happens.

Does the problem occur:
Every time? Or how often? Every time
In other games? Yes
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? When sha1() is not given a constant argument.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown. Happens in at least 513.1527 and 513.1542.

Workarounds: Don't do this?
I just tried 514.1549 and got some very odd results.


I suspect the conversion is not only converting the raw bytes from pseudo-W1252 to UTF-8, it's reading past the end of the bytes. This may be where that rogue '!' was coming from - in 514, I've had results varying from

sha1("a") = '÷ä7ú¥§üá]ܹêêê7vg¸Àð'

to
sha1("a") = '÷ä7ú¥§üá]ܹêêê7vg¸ÀÒ]    ðÒ] '


It seems to get more inconsistent the more stuff goes on in the compile. Likely it's reading other compiler data to convert.
Lummox JR resolved issue with message:
sha1() with a constant string compiled incorrectly.