GRPlatform current secureHashFor: depends on the used String class

Marten,

this should be true on any platform. The hash is computed on a string of bit octets, IOW, binary values. The default encoding is probably going to be UTF-8, so the binary representation of the two string will be different, and therefore the hash. I don’t see any way around it other than forcing the default encoding to be UTF-16 which I don’t know how Grease handles in GLASS. 

Jerry Kott

This message has been digitally signed. 

PGP Fingerprint:

A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5

On 23-07-2018, at 5:26 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

I do not know, if this is an error - but I notice that secureHashFor: is based on the byte representation of the used string:

GRPlatform current secureHashFor: 'vorzimmer' = GRPlatform current secureHashFor: (Unicode16 withAll: 'vorzimmer' )

is false ....

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

... [show rest of quote]

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Yes, but this should be made *very* clear in the documentation ...

Marten

I think one could make a valid argument that the code points should be the source of the bits. e.g. ASCII characters in a Unicode16 string would only have their ASCII code points used, not the internal representation bits.

 Richard Sargent via Glass <[hidden email]> hat am 23. Juli 2018 um 21:02 geschrieben: