The reason you see ASCII values is that ASCII is a proper subset of
unicode. The letter 'A' has value 65 in ASCII and also value 65 as a
Unicode code point. But OpenSCAD is still a Unicode system, not an ASCII
system, because the entire Unicode range is supported. So there's no need
to stop at chr(255), when you also have chr(256), chr(257), and so on.

If you want to represent an array of values between 0 and 255 using a
string, you can still do that, you'll just have represent 0 in a different
way: pick a different code point. Or you could add an offset, and use the
range chr(1) to chr(256) to represent the values 0 to 255. Of course, I'm
not really sure what you're trying to do, but I hope this has helped.

On 17 April 2015 at 12:29, Fantome paul@brownsbrain.com wrote:

doug.moen wrote

Hey thanks! Sometimes the simple answers are the best. Since OpenSCAD is
using Unicode then yes, I can simply use chr(256) to represent a zero. I
like it.

Thanks again. Satisfaction has just increased to 100%.

--
View this message in context: http://forum.openscad.org/How-to-detect-chr-0-tp12351p12409.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Fantome wrote

Note this line in the wiki re chr():

Note: When used with echo() the output to the console for character codes
greater than 127 is platform dependent.

Also code-points above 0x7F are actually stored as 2 bytes

U+0080 U+07FF 2 bytes 110xxxxx 10xxxxxx  wikipedia
http://en.wikipedia.org/wiki/UTF-8

The UTF-8 ASCII 'compatability' in terms if byte code is only for 00-7F.

@Torsten, according to Wikipedia, 0x00 is NULL and is a valid code point.
???

Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/How-to-detect-chr-0-tp12351p12410.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

echo("\u0000" == "\u0020");
ECHO: true

So \u0000 is converted to a space character.

There are a couple of good reasons to not support NUL.
They all stem from the fact that C programs use the NUL character to
terminate a character string.

• One reason might be implementation reasons: a lot of the string APIs
  available to C++ programs use NUL terminated strings.
• Another reason is security related: there are a number of network
  security exploits that are involve the insertion of NUL characters into
  network traffic. There are a couple of projects that build web interfaces
  on top of OpenSCAD, so if a malicious OpenSCAD script has the ability to
  insert NUL characters into these project's web traffic, it might be
  possible to build an exploit.

On 17 April 2015 at 18:12, MichaelAtOz oz.at.michael@gmail.com wrote:

MichaelAtOz wrote

Hmm, I went to a better source, Unicode.org. I couldn't find anything
stating that any values are invalid but I did find this:
*Q: Are noncharacters invalid in Unicode strings and UTFs?

A: Absolutely not. Noncharacters do not cause a Unicode string to be
ill-formed in any UTF. This can be seen explicitly in the table above, where
every noncharacter code point has a well-formed representation in UTF-32, in
UTF-16, and in UTF-8. An implementation which converts noncharacter code
points between one UTF representation and another must preserve these values
correctly. The fact that they are called "noncharacters" and are not
intended for open interchange does not mean that they are somehow illegal or
invalid code points which make strings containing them invalid.
*
Maybe there is some confusion with what I am doing. I'm not looking to print
anything out as in text. I am only interested in the 8bit values. Wether
it's Unicode, ASCII or whatever doesn't really matter because 8 bits will
always be 8 bits, even if they are taken from a 32 bit value.

I looked at the chart on Unicode.org for the values from 0x80 to 0xFF and
didn't see anything unexpected. I'll post my code this weekend. It seems
that I always have a hard time explaining my thoughts and methods. (This is
on me, nobody else.) Perhaps seeing the code will make it clear.

In any case, my original question has been answered and I now have a way to
use chr() to represent 0x00. Thanks for that.

--
View this message in context: http://forum.openscad.org/How-to-detect-chr-0-tp12351p12415.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

If you just want a string of numbers, why not just use a vector? It won't
be 8 bits, it will be integers stored as floats, but as you can see
characters aren't really 8 bits either.

The only difference I can see would be if you do maths on the values but if
do it all modulo 256 with the % operator and floor divisions, etc, you
should be able to emulate 8 bits.

On 18 April 2015 at 04:26, Fantome paul@brownsbrain.com wrote:

nophead wrote

Yup I could most likely do it with the % operator. I'm still new to openSCAd
so I just chose a way and decided to stick with it until either it worked or
I decided it couldn't be done.

I put my code up on thingiverse (http://www.thingiverse.com/thing:779394)
because the end result of it is meant to be a 3D printed object. Anybody
interested in what I did should take a look.

I will look into the modulo 256 stuff next. Maybe I'll redo it all and end
up with a much shorter listing.

thanks again...

--
View this message in context: http://forum.openscad.org/How-to-detect-chr-0-tp12351p12417.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I see now that your input is a string and you basically want to convert it
to binary. Yes it can be done with much less code. Here is a simple example:

function testbit(n, x) = (floor(x / pow(2,n)) % 2) == 1;

function binary(x, n = 7) = n >= 0 ? str((testbit(n, x) ? "1" : "0"),
binary(x, n - 1)) : "";

function asc(c, n = 0) = c == chr(n) ? n : asc(c, n + 1);

text = "ABCD";

for(i = [0 : len(text)-1])
echo(text[i], binary(asc(text[i])));

ECHO: "A", "01000001"

ECHO: "B", "01000010"

ECHO: "C", "01000011"

ECHO: "D", "01000100"

Not very speed efficient as OpenScad seems to lack asc();

On 18 April 2015 at 18:14, Fantome paul@brownsbrain.com wrote:

Here’s an alternate asc() function which trades off ‘infinite’ recursion range for a faster let/search approach on a (overridable) static array:

function asc(ch,chrint=[for(i=[0:255]) [chr(i),i]]) = let(match=chrint[ search([ch],chrint,1)[0] ] )
(len(match)==2)?match[1]:undef;