212 posts
Location
Somewhere in this dimension... I think.
Posted 09 December 2015 - 01:33 AM
Title is slightly misleading in the attempt to shorten it… maybe.
VERSION:1.75 Tested
Older versions probably
DESCRIPTION:Cause: Passing certain ASCII codes including 255 (only one I tested) which is valid (
ÿ is the character, may not appear)
Effect: Windows spits out an error on line 94 (Arguments must be the same length.) If your inside the LUA console/interpreter in CraftOS, it crashes unhandled.
EXPECTED RESULT:ÿ (
Latin small letter y with diaeresis) appears on the screen.REPRODUCTION STEPS:The code
string.char(255)
Is inputted into the LUA console/intrepreter or
print(string.char(255))
Is executed
SCREENSHOT:A picture of the LUA console/interpreter crashing is attached.
Edited on 11 December 2015 - 03:23 AM
1426 posts
Location
Does anyone put something serious here?
Posted 09 December 2015 - 07:41 AM
The expected result should probably be printing a "?": CC can only print ASCII characters - it shouldn't error though.
There is
another issue about this, but seeing as it is a result of the string bug, I'm not sure it is fixable until the string bug is fixed.
Edited on 09 December 2015 - 06:41 AM
7083 posts
Location
Tasmania (AU)
Posted 09 December 2015 - 09:56 AM
Truth be told, if you redirect to term.native() (so that your advanced computer is no longer rendering through a window), ÿ will in fact display… sorta. It messes up the cursor position (for very similar reasons to why term.blit() breaks, I'd imagine - that's the function the window API is calling when your system crashes), but you can certainly get it on screen. Beats me as to when that became possible.
More truth be told,
this crash was reported while the build that introduced it was in beta. Hence I'm guessing that Dan's indeed holding off on addressing it as fixing the "real" bug behind it'll kill two birds (… well, maybe a few
more than two birds) with one stone. I'm also guessing that'll happen with the Lua 5.2 move.
212 posts
Location
Somewhere in this dimension... I think.
Posted 09 December 2015 - 10:16 PM
255 is an extended ASCII character. Otherwise 127 is max. But from BombBloke's observations Extended ASCII is included.
7083 posts
Location
Tasmania (AU)
Posted 10 December 2015 - 01:45 AM
Only some, but yeah, it renders. My guess is Dan was wanting to fulfil those requests for extra language support (which hinge on those accented characters being available).
212 posts
Location
Somewhere in this dimension... I think.
Posted 10 December 2015 - 03:11 AM
Further testing estimates that ASCII characters code 192 and above fail. Other just output ? since it is unrenderable. Table I compiled semi-automatically is attached.
Edited on 10 December 2015 - 07:11 PM
1610 posts
Posted 10 December 2015 - 11:22 PM
Just want to point out that the title says "Windows Dies" which I interpreted as being able to BSOD/crash the Windows operating system from CC - you may want to edit that to say something like "window API error with certain ASCII characters"