C Interpreter and sizeof operator

[ozbear]

If one were writing a C interpreter, is there anything in the standard
standard that requires the sizeof operator to yield the same value for
two different variables of the same type?

Let's assume that the interpreter does conform to the range values
for, say, type int, but allocates storage for the variables based
on their value. So, for two variables foo and bar

int foo = 0; /* interpreter allocates two bytes */
int bar = 200000000; /* interpreter allocates four bytes */

Does the standard require that sizeof foo == sizeof bar thereby
making this allocation scheme broken, unless hidden in some way?
Or is it perfectly acceptable for the sizeof operator to different
results?

Regards, Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mike Wahler]

"ozbear" <oz****@bigpond .com> wrote in message
news:438cdcef.9 338968@news-server...

If one were writing a C interpreter, is there anything in the standard
standard that requires the sizeof operator to yield the same value for
two different variables of the same type?
Yes.

Let's assume that the interpreter does conform to the range values
for, say, type int, but allocates storage for the variables based
on their value. So, for two variables foo and bar

int foo = 0; /* interpreter allocates two bytes */
int bar = 200000000; /* interpreter allocates four bytes */
Note that type 'int' is only required to have a max value of 32767
(but is allowed to be larger).

Also note that the size of a byte (type 'char') must be at least 8
bits (but is allowed to be larger).

Does the standard require that sizeof foo == sizeof bar
Yes. Each type must have a specific size, iow in your
example, the possible ranges of 'foo' and 'bar' must be
the same.
thereby
making this allocation scheme broken, unless hidden in some way?
Or is it perfectly acceptable for the sizeof operator to different
results?

No, not for objects of the same type. Why would you want to do this
anyway? What if I later in the code wanted to write:
foo = 10000;

-Mike

[Skarmander]

ozbear wrote:

If one were writing a C interpreter, is there anything in the standard
standard that requires the sizeof operator to yield the same value for
two different variables of the same type?
Yes. (I know this because I looked up the exact same thing lately.) If x and
y have the same type, sizeof x = sizeof y must hold without exception.

6.5.3.4: "The sizeof operator yields the size (in bytes) of its operand,
which may be an expression or the parenthesized name of a type. The size is
determined from the type of the operand. The result is an integer. If the
type of the operand is a variable length array type, the operand is
evaluated; otherwise, the operand is not evaluated and the result is an
integer constant."

Note that the *value* of the operand is irrelevant. Only its *type* matters.
Therefore the size of an object may *not* depend on its value, but only on
its type. If x and y are of type 'int', then sizeof x = sizeof(int) and
sizeof y = sizeof(int), therefore sizeof x = sizeof y. Bad Things happen if
you violate this.
Let's assume that the interpreter does conform to the range values
for, say, type int, but allocates storage for the variables based
on their value. So, for two variables foo and bar

int foo = 0; /* interpreter allocates two bytes */
int bar = 200000000; /* interpreter allocates four bytes */

Does the standard require that sizeof foo == sizeof bar thereby
making this allocation scheme broken, unless hidden in some way?
Yes.

You can try and fudge this in cases where the application cannot possibly
trip over the wrong size, but it's tricky to do this without violating the
standard, and in an interpreter it's very unlikely to be of any value. Just
pick a constant size for integers (4 bytes happens to be a very common one).
Or is it perfectly acceptable for the sizeof operator to different
results?

No, it's not.

S.

[Christian Bau]

In article <438cdcef.93389 68@news-server>, oz****@bigpond. com (ozbear)
wrote:

If one were writing a C interpreter, is there anything in the standard
standard that requires the sizeof operator to yield the same value for
two different variables of the same type?

Let's assume that the interpreter does conform to the range values
for, say, type int, but allocates storage for the variables based
on their value. So, for two variables foo and bar

int foo = 0; /* interpreter allocates two bytes */
int bar = 200000000; /* interpreter allocates four bytes */

Does the standard require that sizeof foo == sizeof bar thereby
making this allocation scheme broken, unless hidden in some way?
Or is it perfectly acceptable for the sizeof operator to different
results?

sizeof (foo) must be equal to sizeof (bar).

memcpy (&foo, &bar, sizeof (foo)) must have exactly the same effect as a
simple assignment foo = bar. And that assignment must work, so your
interpreter must change the memory allocated to foo from 2 byte to 4
byte.

If I write a function

void f (int* p, int value) { *p = value; }

then calling

f (&foo, 2000000000)

must work. Basically, everything must worked as guaranteed by the C
Standard. As long as the interpreter makes sure that everything works as
it should, it is free to do whatever it likes.

[Christian Bau]

In article <43************ ***********@new s.xs4all.nl>,
Skarmander <in*****@dontma ilme.com> wrote:

You can try and fudge this in cases where the application cannot possibly
trip over the wrong size, but it's tricky to do this without violating the
standard, and in an interpreter it's very unlikely to be of any value. Just
pick a constant size for integers (4 bytes happens to be a very common one).

So if I write

long long i;
char array [100];

for (i = 0; i < 100; ++i) array [i] = i;

the compiler is free to use 1, 2, 3, 4 or any other number of bytes for
i, because it doesn't make any difference to the code. The compiler is
allowed to cheat, as long as you cannot detect that it cheats.

[Skarmander]

Christian Bau wrote:

In article <43************ ***********@new s.xs4all.nl>,
Skarmander <in*****@dontma ilme.com> wrote:

You can try and fudge this in cases where the application cannot possibly
trip over the wrong size, but it's tricky to do this without violating the
standard, and in an interpreter it's very unlikely to be of any value. Just
pick a constant size for integers (4 bytes happens to be a very common one).

So if I write

long long i;
char array [100];

for (i = 0; i < 100; ++i) array [i] = i;

the compiler is free to use 1, 2, 3, 4 or any other number of bytes for
i, because it doesn't make any difference to the code. The compiler is
allowed to cheat, as long as you cannot detect that it cheats.

Yes. The compiler is even free not to use any bytes for i at all and emit a
fully initialized array in the object file somewhere, if this is the only
piece of code that assigns to 'array'.

Obviously, the burden is on the compiler writer to make sure these
optimizations are always safe, but as long as programs have the required
semantics, the standard couldn't care less.

S.

[Default User]

Christian Bau wrote:

memcpy (&foo, &bar, sizeof (foo)) must have exactly the same effect
as a simple assignment foo = bar.

Not exactly. The assignment may be done on an element by element basis,
which would not copy the padding bytes.

For the valid data itself, the two structs will be same of course, but
a bitwise comparison would not necessarily be the same.

That is:

memcmp(&foo, &bar, sizeof foo)

need not evaluate to 0 following foo = bar.

Brian

[Simon Biber]

Note: Brian snipped the declaration of foo and bar.
int foo = 0;
int bar = 200000000;

Brian (Default User) wrote:

Christian Bau wrote:

memcpy (&foo, &bar, sizeof (foo)) must have exactly the same effect
as a simple assignment foo = bar.

Not exactly. The assignment may be done on an element by element basis,
which would not copy the padding bytes.

For the valid data itself, the two structs will be same of course, but
a bitwise comparison would not necessarily be the same.

That is:

memcmp(&foo, &bar, sizeof foo)

need not evaluate to 0 following foo = bar.

What if, as in this case, foo and bar are both ints? Must memcmp
evaluate to zero following foo = bar?

--
Simon.

[Skarmander]

Simon Biber wrote:

Note: Brian snipped the declaration of foo and bar.
int foo = 0;
int bar = 200000000;

Brian (Default User) wrote:

Christian Bau wrote:

memcpy (&foo, &bar, sizeof (foo)) must have exactly the same effect
as a simple assignment foo = bar.

Not exactly. The assignment may be done on an element by element basis,
which would not copy the padding bytes.

For the valid data itself, the two structs will be same of course, but
a bitwise comparison would not necessarily be the same.

That is:

memcmp(&foo, &bar, sizeof foo)

need not evaluate to 0 following foo = bar.

What if, as in this case, foo and bar are both ints? Must memcmp
evaluate to zero following foo = bar?

No. ints can have padding bits. Assignment need not make these padding bits
equal, since all that is required is that the "value" of 'bar' is copied to
'foo'. Values may have multiple representations .

S.

[Kenneth Brody]

Skarmander wrote:

Simon Biber wrote:

Note: Brian snipped the declaration of foo and bar.
int foo = 0;
int bar = 200000000;

Brian (Default User) wrote:

Christian Bau wrote:
memcpy (&foo, &bar, sizeof (foo)) must have exactly the same effect
as a simple assignment foo = bar.

Not exactly. The assignment may be done on an element by element basis,
which would not copy the padding bytes.

For the valid data itself, the two structs will be same of course, but
a bitwise comparison would not necessarily be the same.

That is:

memcmp(&foo, &bar, sizeof foo)

need not evaluate to 0 following foo = bar.

What if, as in this case, foo and bar are both ints? Must memcmp
evaluate to zero following foo = bar?

No. ints can have padding bits. Assignment need not make these padding bits
equal, since all that is required is that the "value" of 'bar' is copied to
'foo'. Values may have multiple representations .

But, on systems that have padding bits, would copying them have any effect?
Does overwriting any padding bytes in structs cause any "bad" behavior?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>