473,226 Members | 1,545 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,226 software developers and data experts.

C Interpreter and sizeof operator

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?
Nov 29 '05 #1
12 1827

"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
Nov 29 '05 #2
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.
Nov 30 '05 #3
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.
Nov 30 '05 #4
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.
Nov 30 '05 #5
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.
Nov 30 '05 #6
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

Nov 30 '05 #7
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.
Dec 1 '05 #8
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.
Dec 1 '05 #9
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>

Dec 1 '05 #10
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.
Dec 1 '05 #11
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
Dec 1 '05 #12
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.
Dec 1 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

70
by: Roy Yao | last post by:
Does it mean "(sizeof(int))* (p)" or "sizeof( (int)(*p) )" ? According to my analysis, operator sizeof, (type) and * have the same precedence, and they combine from right to left. Then this...
2
by: Xiangliang Meng | last post by:
Hi, all. What will we get from sizeof(a class without data members and virtual functions)? For example: class abnormity { public: string name() { return "abnormity"; }
31
by: Anjali M | last post by:
#include <stdio.h> int main() { int number = 10; printf("Number is: %d\n", number); printf("Sizeof of number is: %d\n", sizeof(number++)); printf("Number now is: %d\n", number);
7
by: dam_fool_2003 | last post by:
#include<stdio.h> int main(void) { unsigned int a=20,b=50, c = sizeof b+a; printf("%d\n",c); return 0; } out put: 24
42
by: Christopher C. Stacy | last post by:
Some people say sizeof(type) and other say sizeof(variable). Why?
12
by: sonu | last post by:
#include<stdio.h> main() { int x=10,y; y=sizeof(++x); printf("x=%d\ny=%d\n",x,y); } Oput Put
15
by: Alex Vinokur | last post by:
Why does one need to use two kinds of sizeof operator: * sizeof unary-expression, * sizeof (type-name) ? Their behavior seem not to be different (see an example below). ------ C++ code...
43
by: Richard | last post by:
Could someone point me to why "sizeof x" is/isnt preferable to "sizeof(x)",
28
by: Howard Bryce | last post by:
I have come across code containing things like sizeof int How come that one can invoke sizeof without any parentheses surrounding its argument? Is this admissible within the standard? Can it...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.