DBString #printString oddity

I have a test in GBS which compares the #printString of a two-byte string on the server with that of an equivalent two-byte string on the client. It fails, because the DBString implementation answers a single-byte string.

(I doubt many people are using DBString and almost certainly not relying on its #printString, so this is primarily a warning note.)

My GBS example is:

GBSM evaluate: '
| dblString |
        dblString := DoubleByteString new: 8.
        dblString
            at: 1 put: (16rF1A7 asCharacter);
            at: 2 put: (16rF1D4 asCharacter);
            at: 3 put: (16rF1E5 asCharacter);
            at: 4 put: (16rF127 asCharacter);
            at: 5 put: (16rF154 asCharacter);
            at: 6 put: (16rF165 asCharacter);
            at: 7 put: (16rFB asCharacter).
dblString printString'

It yields a DBString with the expected 10 codepoints 16r0027 16rF1A7 16rF1D4 16rF1E5 16rF127 16rF154 16rF165 16r00FB 16r0000 16r0027

The corresponding VA Smalltalk version is:

| dblString |
        dblString := DBString new: 8.
        dblString
            at: 1 put: (16rF1A7 asCharacter);
            at: 2 put: (16rF1D4 asCharacter);
            at: 3 put: (16rF1E5 asCharacter);
            at: 4 put: (16rF127 asCharacter);
            at: 5 put: (16rF154 asCharacter);
            at: 6 put: (16rF165 asCharacter);
            at: 7 put: (16r00FB asCharacter).
dblString printString

It yields a String with 16(!) codepoints 16r27 16rF1 16rA7 16rF1 16rD4 16rF1 16rE5 16rF1 16r27 16rF1 16r54 16rF1 16r65 16rFB 16r00 16r27. It turns out that the double-byte codepoints which can be represented in 8 bits only require a single byte in the client representation.