Re: Launching apps on 10.13.2

Graham Cox

On 8 Dec 2017, at 4:05 pm, Quincey Morris <> wrote:

On Dec 7, 2017, at 19:06 , Graham Cox <> wrote:

The code in the test app is this:
FWIW, 102 is 0x66, or a lower case “f”.
Ah, makes sense.

Also, I think a “$” at the start of an archive key is an escape character, and so probably shouldn’t be taken literally. However, I don’t know what key you’d need to ask for instead.
I wondered about that myself. I tried just leaving it off, but that didn’t work either. Without the source code for the private ‘old array’ class, it’s hard to guess what to try.

On to the code…

The first few times I tried this, I thought I got inconsistent results, but maybe I just did something wrong. The last several times I tried, I got the same exception as you, but only with the “float” type. All the other types I tried worked.

I think it must have fallen through the one crack in the testing. I’d hate to think they didn’t test it at all… ;-)

One odd thing I noted. If I encoded the array as anything other than float elements (e.g. specifying “@encode(double)” or “@encode(short)”), and decoded with “@encode(float)”, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray decodeArrayOfObjCType:count:at:]: type ('f') or count (6) does not match stored type and count ('d', 6)
but if I encoded the array as “@encode(float)” and decoded it as anything else, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray initWithCoder:]: unable to decode element in array of size (4) and count (6)
It’s very odd.
Indeed. We’ve raised a DTS support incident so that it gets looked at quickly - I would imagine if the bug really is there, we can’t be the only ones screaming about this - unreadable archives with no workaround is quite serious.


Join to automatically receive all group messages.