ToZ85Encoded adds zero termination to C# string about clrzmq4

[metadings]

I implement ZAP for curve.
YEAH!

Well this is adding a \0 character, because the C++ application does expect it...!

I do think there should be, something which encodes/decodes to a string (non-null terminated for C# applications), and something which encodes/decodes into a string (null terminated for C++ applications)...

[gillima]

Hmm I have played arround a bit and found the following:
When I use a string (key), decode it to a byte array, encode it and get the string representation of it, the result is different from the original key, see the following example:

     string orginalKey = "rq:rM>}U?@Lns47E1%kR.o@n%FcmmsL/@{H8]yf7";
     byte[] decodedKey = orginalKey.ToZ85DecodedBytes();  // array size is 32 bytes, so it's fine
     byte[] encoded = decodedKey.ToZ85Encoded();  // array is 41 bytes, there is a 0 at the end
     string copyKey = Encoding.ASCII.GetString(encoded);
     Debug.Assert(copyKey == orginalKey);   // strings are not equal because of the \0 at the end

The bug happend in Z85.cs where in the Encode method +1 is added to the destLen. The following change fixed the issue for me:

     - int destLen = (Int32)(decoded.Length * 1.25) + 1;
     + int destLen = (Int32)(decoded.Length * 1.25);

Because the change is only on C# side in encoding, I don't think there is any impact to C++.

[metadings]

You are on the right way... Do you want to implement a class Platform.iOS?

[metadings]

You made a PR with

        using (var publicKeyData = DispoIntPtr.Alloc(destLen + 1))
        using (var secretKeyData = DispoIntPtr.Alloc(destLen + 1))

Should we not also use just destLen here? I'm asking, because I don't have test cases for Z85.

[gillima]

No, the +1 is because of the null termination of the C++ string which is not needed in C#. I just add it to ensure the buffer to be big enough.

If you whould add it whould happend to a C# string with \0 in it... which would be false...

[metadings]

I suppose this is done in DispoIntPtr.Ansi.AllocStringNative, when doing Marshal.StringToHGlobalAnsi(str). I did that too in that function, when you look down the comment, there I'm adding the 0x00...

[metadings]

AH, the method is never called in Z85.CurveKeypair ... So yes you likely need that +1... :)

[gillima]

This direct points me to something... I implemented the method to return byte[] but I'm not sure this is correct. I did to be consistent because Encode also returns a byte[]. But when I check the zmq documenatation, zmq_encode is returning a char* and this would be a string in C#... think this would also affect some of the extension methods in Z85.ch

[metadings]

Well you're right by returning byte[], because a C char is a C# byte... So that's fine.
I need to remove those Z85.~String methods, they are just confusing...

[gillima]

From zmq docu:

char *zmq_z85_encode (char *dest, const uint8_t *data, size_t size);

uint8_t* -> byte[]
char * -> string

Don't you agree?

[metadings]

No, it is that a C char is a C# byte.
There may also be a definition for uint8_t, which is also a C# byte.

There maybe also a definition for uint16_t, which is a C# UInt16; which then allows to cast to C# char... But you won't do that. Use instead Encoding.UTF8.GetString(bytes) from a C char* or a C# byte[], to get your C# string out of those bytes.

[gillima]

C char has a range of -128..127, C# byte has a range from 0..255, C# sbyte is from -128..127 and is more like a unsigned char or uint8_tin C - but this is not the point here and I really don't want to tell you anything about C
I just think C signature char *zmq_z85_encode (char *dest, const uint8_t *data, size_t size); indicates that the function takes a (C#) byte[] as input and returns a (C#) string... but don't care, I can really live with this.

[metadings]

No, C# char[] and C# string don't have anything to do with C char and C char*.
You may just believe me for now, but once you need it, you will read this message again :)

[gillima]

No, C# char doesn't have anything to do with C char.

I never claimed this. I claimed the C# byte is more like a C unsigned char or uint8_t. But as I wrote, i don't care and will stop here because it dosn't matter.

[metadings]

hehe