Re: Pointer arithmetic error

[Tommy Thorn <tommy@numba-tu.com>]

[Resent for the 3rd time. I seems I can't write to the list]

David Given wrote:
 > Christopher Li wrote:
 > [...]
 >   
 >> You are right that point out a bug (assumption) of sparse which byte 
is 8 bits.
 >> Using bits_in_byte is instead of 8 is better there.
 >> Using bits_in_char assumes char has same bits as byte. That is my read
 >> of the C spec.
 >>     
 >
 > Yes, indeed, I'd managed to get my terminology muddled to the confusion
 > of everyone.
 >
 > Okay, I've gone and looked at the implementation of this stuff; it would
 > appear that modifying the code to supply the back end with units scaled
 > in something other than C chars is actually quite complicated, so I
 > haven't tried to do that. However, I'm enclosing a patch that should,
 > hopefully, fix the cases where it's assuming 8 bit bytes. Hopefully I've
 >  managed to catch all the cases, without breaking the octal parse code...
 >
 > (I haven't used git before; is this the right format?)
 >   

Yes, but it would have been better to have kept all the white space
changes for a separate change so we could just see that relevant changes.

This introduces divides all over the place for all users, replacing a
very cheap constant shift with an expensive divide. All sparse users
would be paying the cost for a feature that is useful for 1 user, I
think we should perhaps think carefully about this.

One obvious solution would be to introduce a BITS_IN_CHAR macro in
target.h defaulting to 8 and let "exotic" architectures redefine it to
bits_in_char. This is very similar to the approach GCC is using.



On a completely unrelated node, I'm excited to see your work on using
sparse for compilation. Hopefully your experience will lead to it being
easier for the next guy. I would like to see sparse target for a simple
abstract machine, but I so far haven't had time to work on it.

Tommy