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.9338968@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.9338968@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***********************@news.xs4all.nl>,
Skarmander <in*****@dontmailme.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***********************@news.xs4all.nl>,
Skarmander <in*****@dontmailme.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>

[Skarmander]

Kenneth Brody wrote:

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?

That's a completely different matter. No, it would not, since padding bytes
in structs are never used for anything (other than meeting alignment
requirements) and can never cause trap representations like padding bits in
integers can. And even in integers, if "foo = bar" copies the padding bits
of 'bar' to 'foo' as well, that's not just perfectly legal, it's what you'd
expect most implementations to do.

The question was whether assignment and memcpy() did the same thing. They
don't. memcpy() gives you stronger guarantees than assignment.

S.

[Default User]

Simon Biber wrote:

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

Oops, guess I did.

It wasn't my intention to muddy the waters.


Brian

[Flash Gordon]

Kenneth Brody wrote:

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?

I believe that doing a memcpy between two objects of identical type is
always OK whether of not there are padding bits.

However, even in the absence of padding bits on an int doing foo=bat
*may* have a different effect to doing memcppy(&foo, &bar, sizeof foo)
and lead to memcmp(&foo, &bar, sizeof foo) returning a non-zero result.
The reason being that 1s complement and sign-magnitude implementations
are allowed (but not required) to have -0 as valid as long as a -0
compares equal to +0 (apart from using memcmp, obviously).
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.