Argument to exposed function can't contain ampersand?

Cloud
1

I have a ‘print’ function exposed via the cloud API for testing my font rendering code, so I can run “spark call print ‘Some text’” and have it displayed on the screen I have attached to my core, and it seems that the string that’s passed can’t seem to contain an ampersand - it gets replaced with a null byte.

I noticed that if you use curl to make the call manually, you can use URL encoding so that, for example, ‘%20’ is replaced with ’ ', and I’ve tried that with ‘%26’, for ‘&’, but it’s the same deal; it gets replaced with a null byte.

I’ve found a thread that describes a similar issue with ‘#’: http://community.spark.io/t/how-to-send-hash-character-to-spark-function/4548/6, which was fixed some time ago, and indeed exposed functions can now receive strings containing every printable ASCII character except the ampersand.

Short of writing my own escaping, is there any way around this?

2

Hi @Nye,

I’ll take a look into this, I suspect we’re running into some http request payload encoding issues, but I’ll double-check. :slight_smile:

Thanks,
David

3

I noticed this too when sending strings to the message torch, my workaround was to replace the ampersand character with another unused one like an A with a dots above it… and have the core swap it back when sent to the display. I also used the same method for smilies, hearts and symbols. it also helped to reduce the number of characters sent to the function.

If you look at the message torch code there is this section to re-map the 16bit character, 0xC3 is the first byte of those characters and 0x84 is the second byte for the Ä character…

if (aText[i]==0xC3) {
if ((int)aText.length()<=i+1) break; // end of text
switch (aText[i+1]) {
case 0x84: c = 0x80; break; // Ä
case 0x96: c = 0x81; break; // Ö
case 0x9C: c = 0x82; break; // Ü
case 0xA4: c = 0x83; break; // ä
case 0xB6: c = 0x84; break; // ö
case 0xBC: c = 0x85; break; // ü
default: c = 0x7F; break; // unknown
}
i += 1;
}

4

Have you tried sending %2526 which is %26 encoded again? I don’t have time to try it, but it is worth a shot.

5

Interesting idea, but no: it results in the function receiving "%26", which I guess is what I'd expect.

Yes, if I end up deciding it's important (and if it's not changed in the mean time) I'll probably do the same. For the moment it's not crucial as I'm only using the cloud function for testing.

Thanks for the replies.

6

Any updates/workarounds?
Seems to still be the case that you can’t send an ampersand through the exposed functions