Jump to content

[1.45] Rednet.send modifies any bytes > 127

25 replies to this topic

#21 immibis

    Lua God

  • Members
  • 1,033 posts
  • LocationWellington, New Zealand

Posted 27 October 2012 - 04:49 AM

View PostElvishJerricco, on 25 October 2012 - 03:33 AM, said:

View Postfaubiguy, on 24 October 2012 - 07:17 PM, said:

I don't see a reason for rednet.send to send strings in the context of ASCII. A string in lua is a series of bytes, and doesn't necessarily store text, ASCII or otherwise. A string can be used to store a sequence of arbitrary bytes. However, as mentioned above, this is likely unintended result of conversion to java and back, and can't be easily fixed.

It's because he's using string.char() and string.byte(). Those functions' purpose are to convert a number to its ASCII character and back. Like i said, strings in lua are objects, so it's not the string's fault. It's the method used to go from number to string. The purpose is to use the ASCII standard which really should behave the way it is here. It is not a bug, it is not bad behavior, it is not Java's fault. It is exactly what it was designed to be.

A string in Lua is a sequence of bytes. Source: "String represents arrays of characters. Lua is 8-bit clean: strings can contain any 8-bit character, including embedded zeros ('0')"

It does not specifically mention ASCII.

In the same reference manual:
"string.byte (s [, i [, j]])
Returns the internal numerical codes of the characters s[i], s[i+1], ···, s[j]. The default value for i is 1; the default value for j is i."

"string.char (···)
Receives zero or more integers. Returns a string with length equal to the number of arguments, in which each character has the internal numerical code equal to its corresponding argument."

Notice that characters are just numbers from 0 to 255. ASCII is just the way they're printed.

View Postdan200, on 25 October 2012 - 02:23 PM, said:

Rednet isn't for sending "bytes", it's for sending strings of text. if you're trying to use strings to encode binary data using string.char/string.byte, you're making a lot of assumptions about character sets that may not hold true. If you really -must- send data in binary (i can't think why you would, sending the lua data you want using textutils.serialise, or just strings of numbers, is much simpler), write a base64 encoder.
The only assumption is that all numbers from 0 to 255 are valid characters, which the Lua reference manual specifically says is true.

View PostCloudy, on 25 October 2012 - 06:22 PM, said:

A simple solution is base64 :D/> Packet size is not important in a system where packet size is unlimited.
It is still a bug.

#22 Cloudy


  • Members
  • 2,543 posts

Posted 27 October 2012 - 09:02 AM

A bug which may be completely out of our power to fix. Literally all we do is use the built in LuaJ function to get the string from Lua. We then pass it to the modem where it gets converted back into a Lua string, once again using LuaJ. Our options really are limited.

I will look into it - but I'm not going to waste too much time on it considering sending binary data is not what the function is intended for anyway.

#23 Anavrins

  • Members
  • 775 posts

Posted 23 September 2013 - 10:57 AM

View PostCloudy, on 25 October 2012 - 06:22 PM, said:

A simple solution is base64 :P/>

Packet size is not important in a system where packet size is unlimited.
Sorry for gravedigging this thread, but the problem with that is, assuming my little research is correct, if the binary data you want to be converted to base64 contains a byte greater than ~0xC0,
it will be decoded wrongly, since something like ( string.char(195) .. string.char(70) ) will return the Extended Ascii caracter "Æ" and not the individual two character.

Either that, or maybe I need my base64 function to return the string in a byte array format, instead of a string?

#24 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,462 posts

Posted 23 September 2013 - 11:44 AM

You're definitely doing it wrong. Only the encoded data should be represented as a string, the unencoded/decoded binary data should always be numbers in a table.

#25 electrodude512

  • Members
  • 167 posts
  • LocationEastern USA

Posted 23 September 2013 - 03:10 PM

How is the top byte cutoff bug out of your reach just because it's part of LuaJ? LuaJ uses the MIT license, which says you can modify it however you want with credits. If you don't plan to update to Lua 5.2 (which you apparently don't), is there any reason slightly modifying the lua interpreter could break anything or cause any problems in the future? If you do eventually decide to upgrade to Lua 5.2, then you could just diff the original LuaJ 5.1 and your modified version and apply the patch (possibly manually) to LuaJ 5.2.

#26 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,462 posts

Posted 23 September 2013 - 03:24 PM

That's not how it works.

There are currently no plans to move away from Lua 5.1.


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users