NULL

23 views
Skip to first unread message

Drs Mark Schonewille

unread,
Aug 31, 2024, 5:47:26 AMAug 31
to SuperCard Discussion
Hi,

Am I correct observing empty scripts containing the NULL char? What could be a reason for this?

I'm writing an SC2XML script. Can I safely assume that scripts containing NULL are supposed to be empty?

Something like (pseudocode):

if the script of cd button x contains NULL then
 -- ignore
else
 put addScriptOfThisObjectToTreeXML(cd button x) after theTree
end if

Would this be correct? Are there any other reasons why scripts would contain NULL?
-- 
Mark Schonewille
Economy-x-Talk
KvK 50277553
VAT NL002099948B21
https://ecxtalk.nl
https://www.nt2.nu

Programming LiveCode for the Real Beginner
http://www3.economy-x-talk.com/file.php?node=programming-livecode-for-the-real-beginner

Drs Mark Schonewille

unread,
Aug 31, 2024, 6:22:33 AMAug 31
to SuperCard Discussion
I've found another problem in a specific stack.

A script of a background contains bitmap data. It looks like someone did

set the script of bg x to the picturedata of grc y

Would it make sense to do anything like that?! Would anyone ever want to save bitmap data in a script?!

Best,

Mark Schonewille
Economy-x-Talk
KvK 50277553
VAT NL002099948B21
https://ecxtalk.nl
https://www.nt2.nu

Programming LiveCode for the Real Beginner
http://www3.economy-x-talk.com/file.php?node=programming-livecode-for-the-real-beginner
Op 31-8-2024 om 11:47 schreef Drs Mark Schonewille:

MARK LUCAS

unread,
Aug 31, 2024, 12:01:15 PMAug 31
to 'MARK LUCAS' via SuperCard Discussion
Hi Mark,

These issues might be related.

Although AFAICR I never resorted to that particular kludge myself, evidently in the time before user properties were invented it was relatively common practice for ambitious scripters to stash various types of non-script content (especially binary data, which tends to get horribly mangled if stored in fields) in object scripts - basically just for want of a better mechanism to attach arbitrary stuff to objects or contexts. For whatever reason old habits die hard, and some grizzled veterans persisted in the practice long after it became unnecessary - even though it was STRONGLY discouraged.

Basically SuperCard shouldn’t ever insert NULL bytes in your scripts all on its own, but it will happily do so if asked.

But just like in fields, binary data (especially if it contains characters < ASCII 32) typically won’t display legibly, so even scripts containing large blocks of binary data may appear empty if you try to edit them. The binary content itself may also get mangled if just unpacked for editing and then saved (even if you don’t touch it) because the interpreter sometimes tries to strip off what it views as garbage bytes at the beginning or end of a script (to work around an ancient bug that apparently sometimes added stray binary bytes to scripts during conversion from HyperCard stacks).

So short form: yes there really could be a NULL byte (and even a LOT more invisible data) in scripts (especially of old projects) if someone once decided to put it there, but this practice is VERY unsafe in SuperCard (so any script you find doing it should definitely be changed ASAP to store that data in a user prop instead). Likewise you also shouldn’t assume anything you find in a script that starts with a NULL is really just one byte long, or that you can reliably clear binary data out of a script by selecting all and deleting in the Script Editor (because binary data may not be 100% editable), and you should use a ’set’ command to clear it instead to be sure. Nor for that matter can you assume all such stored non-script data will contain one or more NULLs (although the potential occurrence of NULLs in it is probably what once led someone to stash it there in the first place).

Thus your strategy for avoiding specifically any scripts that contain NULL is basically sound, but you should be aware that NULL is not the only troublesome byte potentially lurking in such ‘abused’ object scripts. So if you’re really trying to skip scripts with non-script data in them (not just NULLs) then you might instead have to loop thru each script character-by-character looking for obviously non-script bytes (i.e., < ASCII 32). Of course even this isn’t a 100% reliable indicator of script vs. non-script content, but it should at least catch the most problematic content.

Does that help any?

-Mark


-- 
You received this message because you are subscribed to the Google Groups "SuperCard Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to supercard-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/6364a401-6740-4164-8902-406f13ae857a%40economy-x-talk.com.

Uli Kusterer

unread,
Sep 3, 2024, 10:45:46 AMSep 3
to 'David Coggeshall' via SuperCard Discussion, Uli Kusterer
On 31. Aug 2024, at 12:22, Drs Mark Schonewille <m.scho...@economy-x-talk.com> wrote:
> I've found another problem in a specific stack.
>
> A script of a background contains bitmap data. It looks like someone did
>
> set the script of bg x to the picturedata of grc y
>
> Would it make sense to do anything like that?! Would anyone ever want to save bitmap data in a script?!

That sounds extremely ill-advised. I mean, technically lines between handlers are just ignored, but SuperCard will go through that bunch of binary data and try to find bits of script in it. Depending on how often the Byte with value 13 (return) occurs in that pictureData, that may be fast (line doesn't start with "on" or "function", ignore), or slow (lots of short lines containing garbage bytes to be skipped).

But I guess in practice this won't hurt, because it's very likely a pictureData would contain something that looks like a valid script that could lead to you seeing a syntax error. If you're that lucky to hit that bug, I'd recommend you play the lottery 😜

In summary: I wouldn't use this technique, but if you have a project that uses it, you are probably reasonably safe. At least as long as SuperCard uses the WASTE text engine. Apple's text engine doesn't really like null characters in the middle of text (they're used as a "text ends here" marker in lots of places), so might stop working if that ever changes.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

Reply all
Reply to author
Forward
0 new messages