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

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

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.

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

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