www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - bitpointer and offsets

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Pointers to bits in arrays do not behave as expected...

I would like them to point to the byte (rounded down)
that the bit is located in... This would make (&ba[4])
and (ba + 4) point to the same address, which I expect.
(bit pointers seem to work OK, it's just taking the adress
of bits in arrays that do not seem to be fully implemented)

That is, both should get the address of the ptr itself,
since 4 ist just half a byte. Offset 8 gets the next byte.

Test program is attached, that asserts expected behaviour
from three versions: bool (bit), wbool (byte), dbool (int)

While pointers to individual bits can never be had, it
should work OK as long as the index is a multiple of 8...

--anders
Feb 11 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
I wrote:

 Pointers to bits in arrays do not behave as expected...
Typical, I made a typo in the program I tested on Linux :-P
 Test program is attached, that asserts expected behaviour
 from three versions: bool (bit), wbool (byte), dbool (int)
 
 While pointers to individual bits can never be had, it
 should work OK as long as the index is a multiple of 8...
It currently throws an ArrayBoundsError on Linux (DMD), while GDC silently calculates the wrong address instead. So I guess it's just a undocumented compiler difference ? Correct program attached. --anders
Feb 11 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
 Pointers to bits in arrays do not behave as expected...
 
 I would like them to point to the byte (rounded down)
 that the bit is located in... This would make (&ba[4])
 and (ba + 4) point to the same address, which I expect.
 (bit pointers seem to work OK, it's just taking the adress
 of bits in arrays that do not seem to be fully implemented)
<snip> I'm not sure about this. IMO allowing &ba[4] or (ba + 4) at all is asking for trouble - people will actually expect the pointer to point to that bit, and then be confused when they find that it actually points to the bit at the beginning of its byte. My inclination is that attempting to point to a bit that isn't on a byte boundary should be an error - compile-time if it can be determined then, otherwise run-time. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 11 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 I'm not sure about this.  IMO allowing &ba[4] or (ba + 4) at all is 
 asking for trouble - people will actually expect the pointer to point to 
 that bit, and then be confused when they find that it actually points to 
 the bit at the beginning of its byte.
 
 My inclination is that attempting to point to a bit that isn't on a byte 
 boundary should be an error - compile-time if it can be determined then, 
 otherwise run-time.
OK, but it is not working in GDC at the moment anyhow... &ba[0] and &ba[8] returns the wrong pointer adress, and &ba[4] does not throw an ArrayBoundsError like in DMD. An exception is probably easier to understand, and you do get one if you try to slice at a non-byte boundary ? --anders
Feb 11 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 My inclination is that attempting to point to a bit that isn't on a byte 
 boundary should be an error - compile-time if it can be determined then, 
 otherwise run-time.
Here is the updated test, now checking for an ArrayBoundsError on &ba[4] Works with DMD, fails with GDC (with -version=bool, that is)
 Error: AssertError Failure bitpointer.d(54)
--anders
Feb 11 2005