Now test case No: 21 on http://wiki.squeak.org/squeak/1183
with details here http://wiki.squeak.org/squeak/1261

Details need to be refined, in particular an interaction diagram
     (e.g use https://sequencediagram.org/ to draw the diagram)
would be helpful and some references to definitions and a summary of
the questions.





On 7/1/18, K K Subbu <kksubbu.ml at gmail.com> wrote:
> I dug into this a little deeper today as it gave me an opportunity to
> study ImageSegments. I extracted the cs from 001 and used a binary
> editor to search for version number. I found one sequence 16r64006619
> which decodes to a big-endian 6502 ImageSegment. In 002, I found the
> sequence 16r66190073 which decodes to a little-endian segment.
>
> When I dropped 001 pr into Squeak 5.2alpha (18120/64b/Ubuntu) and
> examined the resulting error stack I found something strange.
>
> Before the endian check in LegacyImageSegment>>#comeFullyUpOnReload, the
> instance is already created in DataStream>>#next method assuming
> little-endian, so segment ivar first word is 16r66190064. Therefore, the
> endianness check in:
>
> ImageSegment>>endianness
> ... ^(segment first bitShift: -24) asCharacter == $d ifTrue: [#big]
> ifFalse: [#little]
>
> ends up checking the wrong byte for  endianness. I changed this code to
> check for both $s and $d and confirmed that endian check is incorrect at
> this point.
>
> I got stuck here. How should one fix this error?
>
> Regards .. Subbu
>
>