DiAvOl said:

<snip>

>> So you'd probably define
>> UINT_MAX as 268435455 and ignore the top four bits completely. They'd
>> still be there, of course, but they would not contribute to the value of
>> the unsigned int. In fact, you'd probably have to mask them out during
>> calcs, just in case some bright spark managed to set them anyway.
>
> What values would those 4 top "padded bits" contain? 0 or 1?

One or other of those, yes.

> I'm trying to figure out if padding bits affects the code in any way,
> for example what if the user wanted to use those 4 top bits for
> bitwise operations?

The user could actually do this, of course, simply by accessing the object
representation via type punning:

unsigned int n = some_value;
unsigned char *p = (unsigned char *)&n;
/* can now write to n's object representation via p[0] through p[(sizeof n)
- 1] */

If the user chooses to bitshift via a series of p[i] hacks, he could, and
the padding bits would then muddy the waters. But if the user instead
shifted the unsigned int itself, well, that's a value-based operation, so
the padding bits would have no effect on the value of the shifted unsigned
int (and the implementation would have to ensure that this was the case).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Thu, 18 Oct 2007 18:44:05 -0400, pete wrote:

> Richard Heathfield wrote:
>> int count_value_bits_in_unsigned_int(void)
>> {
>> int rv = 0;
>> unsigned int n = UINT_MAX;
>> while(n > 0)
>> {
>> ++rv;
>> n >>= 1;
>> }
>> return rv;
>> }
>
> rv should be type unsigned, instead of type int.
> The number of value bits in type unsigned isn't
> guaranteed to be representable as an int type value.
That'd require one unsigned int to occupy at least 4 KB
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

On Thu, 18 Oct 2007 18:44:05 -0400, pete wrote:

> The number of value bits in type unsigned isn't
> guaranteed to be representable as an int type value.

Finding the greatest lower bound for the fraction of padding bits
among the bits of int on any implementation where log2(UINT_MAX+1.0)
is greater than INT_MAX is left as an exercise to the reader.

Now an implementation which wastes more than 99.5% (Hint: unless
I had something wrong, this is strictly less than the greatest
lower bound) of the bits in an int is an implementation I would
rather never have *anything* to do with (including "being to
within one light-year of each other").
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

"Army1987" <army1987@NOSPAM.it> a écrit dans le message de news:
pan.2007.10.20.12.47.07.181515@NOSPAM.it...
> On Thu, 18 Oct 2007 18:44:05 -0400, pete wrote:
>
>> Richard Heathfield wrote:
>>> int count_value_bits_in_unsigned_int(void)
>>> {
>>> int rv = 0;
>>> unsigned int n = UINT_MAX;
>>> while(n > 0)
>>> {
>>> ++rv;
>>> n >>= 1;
>>> }
>>> return rv;
>>> }
>>
>> rv should be type unsigned, instead of type int.
>> The number of value bits in type unsigned isn't
>> guaranteed to be representable as an int type value.
> That'd require one unsigned int to occupy at least 4 KB

And the corresponding int representation to have at least 16368 padding bits
;-)

--
Chqrlie.

On Sat, 20 Oct 2007 15:11:26 +0200, Charlie Gordon wrote:

> "Army1987" <army1987@NOSPAM.it> a écrit dans le message de news:
> pan.2007.10.20.12.47.07.181515@NOSPAM.it...
>> On Thu, 18 Oct 2007 18:44:05 -0400, pete wrote:
>>> rv should be type unsigned, instead of type int.
>>> The number of value bits in type unsigned isn't
>>> guaranteed to be representable as an int type value.
>> That'd require one unsigned int to occupy at least 4 KB
>
> And the corresponding int representation to have at least 16368 padding bits
> ;-)

Have you found a way for such an implementation to have less than
32752 padding bits in int?
(Yes, "at least 16368" is still true if the greatest lower bound
is 32752, but I wander if you found that that lower bound is
wrong.)
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

"Army1987" <army1987@NOSPAM.it> a écrit dans le message de news:
pan.2007.10.21.08.54.53.234455@NOSPAM.it...
> On Sat, 20 Oct 2007 15:11:26 +0200, Charlie Gordon wrote:
>
>> "Army1987" <army1987@NOSPAM.it> a écrit dans le message de news:
>> pan.2007.10.20.12.47.07.181515@NOSPAM.it...
>>> On Thu, 18 Oct 2007 18:44:05 -0400, pete wrote:
>>>> rv should be type unsigned, instead of type int.
>>>> The number of value bits in type unsigned isn't
>>>> guaranteed to be representable as an int type value.
>>> That'd require one unsigned int to occupy at least 4 KB
>>
>> And the corresponding int representation to have at least 16368 padding
>> bits
>> ;-)
>
> Have you found a way for such an implementation to have less than
> 32752 padding bits in int?
> (Yes, "at least 16368" is still true if the greatest lower bound
> is 32752, but I wander if you found that that lower bound is
> wrong.)

No, your lower bound seems good.

--
Chqrlie.