Keith Thompson <(EMail Removed)> writes:
> Tim Rentsch <(EMail Removed)> writes:
>> Keith Thompson <(EMail Removed)> writes:
> [...]
>>> For example, `(size_t)1 / 2` would yield a result that would
>>> compare equal to 0, but if you look at the padding bits of the
>>> result and interpret them as fractional bits, you can interpret
>>> it as 1/2 (a value midway between 0 and 1).
>>
>> If you think about this a little while I expect you'll see that
>> expressions like (size_t)1 / 2 must not set any "fraction" bits.
>> This expression is welldefined by the Standard  it must behave
>> exactly like 0 in all respects for all subsequent operations (ie,
>> operations whose behavior is defined by the Standard). The only
>> value operations that produce size_t representations with nonzero
>> fractions must have an element of undefined behavior, or possibly
>> implementationdefined behavior. This expression is completely
>> defined so it mustn't do that.
>
> Hmm.
>
> There can be representations for an integer 0 other than allbitszero,
> so I'm not sure that having `(size_t)1 / 2` set some of the
> padding/fraction bits to 1 would be forbidden. But certainly
> `(size_t)1 / 2 * 2` must be 0.
>
> On the other hand, we'd want `sizeof (_Nybble[2])` to denote 1
> 8bit byte, and `sizeof (_Nybble[2]) / 2` to denote 1 4bit nybble.
To get that result, you could use
sizeof (char[ sizeof(nibble[2]) / 2. ])
taking advantage of a companion extension that allows floatingpoint
values as integer expressions in array bounds expressions. (Note
for purists: after doing a #include <nibble.h>.)
<editorial>
Spelling nibble with a 'y' rather than 'i' is an affectation.
There is good reason to use 'y' rather than 'i' in byte, and
it also makes sense phonetically. Neither is true for nibble.
</editorial>
> The only way I can think of to make this work consistently
> would be to add another padding bit to size_t, a flag that
> indicates whether it's an ordinary C size value or something
> that takes nybbles into account.
Possible. I don't think it's absolutely necessary, but it
might be worth trying out.
> I'm even more convinced that it wouldn't be worth the effort.
> The C language is not conveniently portable to 4bit
> addressable systems (or trinary systems, or analog systems, or
> ...).
I think you're assuming the target of such an implementation
would be a fourbit system. That needn't be the case. Certainly
I would like a C implementation on a large system that supported
fourbit, twobit, and onebit quantities.
