small fixes (was: Snapshot binary compatibility ?)

Jecel Assumpcao Jr jecel at merlintec.com
Tue Jul 2 18:28:27 UTC 2002


On Monday 01 July 2002 18:02, Harald Gliebe wrote:
> That is caused by the different X servers, if I redirect the display
> from a Sparc VM to a linux box, I also get these boxes, while the
> other way round (Linux VM, Sun's X server) everything looks fine.

I should have done this test too, but this was what I expected. BTW, I 
was wrong about the "unknown font: arialBold" thing - it also happens 
in Linux whenever I open an evaluator.

> Don't know what would be the best place to handle the difference.

It is best to fix this at the Self level. The newlines shouldn't be 
there and we can make them all go away by executing

  (browse childrenOf: traits labelMorph) do: [ | :m. v |
      v: m reflectee.
      (v morphTypeName == 'labelMorph') && "skip clockMorphs and such"
      [(v label lastIfAbsent: '.') = '\n'] ifTrue: [
         v label: v label copyWithoutLast
      ]
]

Of course, any new labels created in whatever way these were created 
will have the same problem so that code should be fixed as well.

> > [ strncpy and strncat ]
>
> This is IMHO a bug in Sun's code that showed up only under linux
> (probably due to different malloc implementations). The context of
> this line is: buffer = (char*) malloc(size + 1);
>   strncpy(buffer, result, size);
>   buffer[size] = '\0';
> The original strncat appends result to the newly allocated buffer
> after the first '\0', depending on the contents of the malloc'd
> buffer this may overwrite arbitrary memory. strncpy just copies the
> result in the right place. Since the original code works on Solaris,
> I assume their malloc will at least clear the first byte of the
> returned memory.

You are probably right.

-- Jecel



More information about the Self-interest mailing list