Re: [sdcc-devel] Separate _Bool from bit?

[Jan W. <we...@ef...>]

>But what about the problem of generic pointers? Wouldn't that require 
>special-case handling in many places, and for some architectures, like 
>the Z80 increase pointer size?

No, it wouldn't. A generic pointer to bit is the same issue as a generic pointer to any other object.

The issue with address space mentioned in your other ("lost") post IS an issue, though. I have no simple answer at this point; as a naive approach assume that all _Bool-s have to reside within a 8kB segment. Generally, pointer size and address space size is always an issue, and this should perhaps be discussed separately (e.g. several '51 derivatives - some already supported by SDCC - have >64kB native address space already, and this IS already an issue).

Conversion to *void is not an issue - there is NO implication in converting such *void to any OTHER type of pointer, so this is purely a formal requirement. 


>The follwoing applies to the Z80, it might or might not apply to other 
>architectures supported by sdcc.
>
>Assume, that we have 8 _Bools in bytes A and B, e.g.
>_Bool A[8], B[8];
>
>Now, since sizeof(_Bool) has to be at least one, we get sizeof(A) == 
>sizeof(B) == 8.

No, this is not true.

6.5.3.4 clearly states, that "When applied to an operand that has array type, the result is the total number of bytes in the array."

memcopy using such sizeof would 

Taking sizeof() of a _Bool-containing object or type shall most probably issue a warning anyway; and we shall probably provide extended functions with bit-wise size/address/offset taking allowing unambiguous access.



>Thus someone might write the following code:
>
>memcpy(A, B, 8);

Which is entirely foolish to write.
memcpy() is a *string* handling function, copying *characters* (not even bytes!); it is not reasonable to expect that it will know how to handle _Bool arrays correctly.

We can of course provide a library of equivalent but appropriately written _Bool manipulation utilities.

Jan