On Thu, 5 Apr 2001, Christoph Reichenbach wrote:
> > okay, thanks for the explanation. Would other conversions to 15 bits
> > possibly cause problems? For instance, something being put on the stack
> > beyond 32k (via 16-bit variable) and then not being able to be accessed by
> > a 15-bit variable? Or, not enough stack space appearing to be present,
> > causing an overflow?
>
> The stack is part of the lower regions of the global address space in the
> SCI memory model, so it won't have any problems of this kind, but
> issues of this kind have traditionally been causes of interesting
> problems for object pointers.
Okay, I'll avoid reporting stack-related variables being converted.
> I'm pretty sure there's a large number of bit info losses which 'lint'
> will point out. A few bugs might be hidden in there, but we'd
> have to wade though a lot of code to find them.
> Still, this might be worthwhile if you feed those lint reports in small
> portions...
Will do. I'm already verifying/filtering a lot of things out, just needed
to be sure of those few things. FYI, I'm using PC-Lint from Gimpel
software (http://www.gimpel.com).
--
http://www.clock.org/~matt
