Explanation of sizeof(...) request

S

signuts

I'm aware of what sizeof(...) does, what I would like to know is if
sizeof(...) is compiled in or a function that's executed at run-time.

Like for example

{
int a;

printf("a is %d bytes\n", sizeof(a));
}
would this yield the same "machine code" as it's constant value:
{
int a;
printf("a is %d bytes\n", 4);
}

Another thing I just thought of while writing this up is how are
sizeof(...) and pointers computed? is a pointer architecture specific?
a pointer of type int* and char* both yield 4 bytes on my x86 32bit
machine.

Thank ya much
 
A

Allan Bruce

signuts said:
I'm aware of what sizeof(...) does, what I would like to know is if
sizeof(...) is compiled in or a function that's executed at run-time.

Like for example

{
int a;

printf("a is %d bytes\n", sizeof(a));
}
would this yield the same "machine code" as it's constant value:
{
int a;
printf("a is %d bytes\n", 4);
}

Another thing I just thought of while writing this up is how are
sizeof(...) and pointers computed? is a pointer architecture specific?
a pointer of type int* and char* both yield 4 bytes on my x86 32bit
machine.

Thank ya much

I dont know the answer but I could stab a guess.
The sizeof is calculated at run-time unless the compiler has suitable
optimisation. For example, you say that sizeof(int) is 4Bytes on your
machine, therefore, one would expect the compiler to use this rather than
calculating the sizeof at runtime. However, for strings etc. the sizeof is
not known at compile time therefore must be calculated at runtime.
I believe the pointers on your architecture are 4Bytes since you are using a
32-bit architecture, but I could be wrong.
Allan
 
C

Chris Dollin

Allan said:
I dont know the answer but I could stab a guess.
The sizeof is calculated at run-time unless the compiler has suitable
optimisation.

sizeof is a compile-time constant [except for C99 variable-length
arrays]. The compiler is, of course, at liberty to recompute it
at run-time, or to insert arbitrary calculations for fun in your
code, but few of them do.
For example, you say that sizeof(int) is 4Bytes on your
machine, therefore, one would expect the compiler to use this rather than
calculating the sizeof at runtime. However, for strings etc. the sizeof
is not known at compile time

Wrong. The sizeof() is known, although the strlen() probably isn't.
therefore must be calculated at runtime.
I believe the pointers on your architecture are 4Bytes since you are using
a 32-bit architecture, but I could be wrong.

A 32-bit machine might have 16-bit bytes. It almost certainly doesn't,
but it could. Also a 32bit machine might have bigger-than-32bit C pointers
(eg for byte offsets on a word-based machine); again, his machine almost
certainly doesn't, but one shouldn't make assumptions one doesn't need to.
 
A

Allan Bruce

signuts said:
Thanks , it's starting to make sense.
However, for strings etc. the sizeof is
not known at compile time therefore must be calculated at runtime.
I'm not sure if this is correct

This example code prints 4 for each line
struct my_s {
int a,b,c;
char buf[32];
};

int main(int argc, char **argv) {
struct my_s *a;
char *b;

printf("size of *a is %d\n", sizeof(a));
printf("size of *b is %d\n", sizeof(b));

exit(EXIT_SUCCESS);
}

I'd be interested to see what a pointer returns on a 64-bit machine, would
it be 8?

Of course it will - all you are doing is evaluating the size of pointers
again, if you do sizeof(*a) then you will get a decent answer, btw dont try
sizeof(*b) as it will cause undefined behaviour as it stands, but if you
were to have:

char Name[] = "Allan Bruce";
char *pName;

pName = Name;

printf("%d %d\n", sizeof(pName), sizeof(*pName));

This will return

4 12

4 is because you are getting the size of the pointer, and 12 because the
string is 12 chars long (this needs a NULL terminator stop undefined
behaviour".
Allan
 
A

Allan Bruce

Allan Bruce said:
signuts said:
Thanks , it's starting to make sense.
However, for strings etc. the sizeof is
not known at compile time therefore must be calculated at runtime.
I'm not sure if this is correct

This example code prints 4 for each line
struct my_s {
int a,b,c;
char buf[32];
};

int main(int argc, char **argv) {
struct my_s *a;
char *b;

printf("size of *a is %d\n", sizeof(a));
printf("size of *b is %d\n", sizeof(b));

exit(EXIT_SUCCESS);
}

I'd be interested to see what a pointer returns on a 64-bit machine, would
it be 8?

Of course it will - all you are doing is evaluating the size of pointers
again, if you do sizeof(*a) then you will get a decent answer, btw dont try
sizeof(*b) as it will cause undefined behaviour as it stands, but if you
were to have:

char Name[] = "Allan Bruce";
char *pName;

pName = Name;

printf("%d %d\n", sizeof(pName), sizeof(*pName));

This will return

4 12

4 is because you are getting the size of the pointer, and 12 because the
string is 12 chars long (this needs a NULL terminator stop undefined
behaviour".
Allan

actually void this! I forgot strlen(*pName) will return 12, and sizeof wont.
Sorry
 
A

Allan Bruce

Chris Dollin said:
Allan said:
I dont know the answer but I could stab a guess.
The sizeof is calculated at run-time unless the compiler has suitable
optimisation.

sizeof is a compile-time constant [except for C99 variable-length
arrays]. The compiler is, of course, at liberty to recompute it
at run-time, or to insert arbitrary calculations for fun in your
code, but few of them do.
For example, you say that sizeof(int) is 4Bytes on your
machine, therefore, one would expect the compiler to use this rather than
calculating the sizeof at runtime. However, for strings etc. the sizeof
is not known at compile time

Wrong. The sizeof() is known, although the strlen() probably isn't.

You are completely correct - I was getting a bit muddled up
Allan
 
B

bd

I dont know the answer but I could stab a guess.
The sizeof is calculated at run-time unless the compiler has suitable
optimisation. For example, you say that sizeof(int) is 4Bytes on your
machine, therefore, one would expect the compiler to use this rather than
calculating the sizeof at runtime. However, for strings etc. the sizeof is
not known at compile time therefore must be calculated at runtime.
I believe the pointers on your architecture are 4Bytes since you are using a
32-bit architecture, but I could be wrong.
Allan


No, strings are known at compile-time, or are a pointer. In either case,
it's a fixed length. The only time when run-time calculation is necessare
is with C99 variable-length arrays, e.g.:

void foo(int x){
int bar[x];
printf("sizeof bar = %zu\n", sizeof bar);
}

Many compilers do not yet support this, however.
 
B

bd

signuts said:
Thanks , it's starting to make sense.
However, for strings etc. the sizeof is
not known at compile time therefore must be calculated at runtime.
I'm not sure if this is correct

This example code prints 4 for each line
struct my_s {
int a,b,c;
char buf[32];
};

int main(int argc, char **argv) {
struct my_s *a;
char *b;

printf("size of *a is %d\n", sizeof(a));
printf("size of *b is %d\n", sizeof(b));

exit(EXIT_SUCCESS);
}

I'd be interested to see what a pointer returns on a 64-bit machine, would
it be 8?

Of course it will - all you are doing is evaluating the size of pointers
again, if you do sizeof(*a) then you will get a decent answer, btw dont try
sizeof(*b) as it will cause undefined behaviour as it stands, but if you
were to have:

No, sizeof(*b) is legal, and will be 1. I don't think you understand with
sizeof does.
char Name[] = "Allan Bruce";
char *pName;

pName = Name;

printf("%d %d\n", sizeof(pName), sizeof(*pName));

This will return

4 12

4 is because you are getting the size of the pointer, and 12 because the
string is 12 chars long (this needs a NULL terminator stop undefined
behaviour".

Wrong. sizeof *pName will be 1. strlen(pName) will be 11, however.
sizeof Name, however, will be 12.
 
E

Emmanuel Delahaye

In 'comp.lang.c' said:
I'm aware of what sizeof(...) does, what I would like to know is if
sizeof(...) is compiled in or a function that's executed at run-time.

'sizeof' returns a constant of type 'size_t' evaluated at compile time.
Like for example

{
int a;

printf("a is %d bytes\n", sizeof(a));

printf ("a is %lu bytes\n", (unsigned long) sizeof a);

or in C99:

printf ("a is %zu bytes\n", sizeof a);
}
would this yield the same "machine code" as it's constant value:
{
int a;
printf("a is %d bytes\n", 4);
}

Yes, assuming that on you implementation, sizeof (int) == 4.
Another thing I just thought of while writing this up is how are
sizeof(...) and pointers computed?

By the compiler in an implentation-dependent manner.
is a pointer architecture specific?
Yes.

a pointer of type int* and char* both yield 4 bytes on my x86 32bit
machine.

And your question is?
 
E

Emmanuel Delahaye

In 'comp.lang.c' said:
I'd be interested to see what a pointer returns on a 64-bit machine, would
it be 8?

The C language can't give an answer to implementation-specific questions.
Please try it yourself, or ask to a newsgroup dedicated to theses platforms.
 
C

Chris Dollin

Rishix said:
The sizeof is calculated at run-time unless the compiler has suitable

No. 'sizeof' is computed at compile-time. Always.

int nit(int a) {
int b[a];
return sizeof b;
}
K&R says
For array declaration if parameter is present it should be constant
expression which is not the case here.

C99 says that a non-constant expression is allowed. So sizeof need
not be computed at compile-time if you have a C99 compiler.
 
E

Emmanuel Delahaye

In said:
Chapter and verse, please.

It would be a remarkable feat for a C99 compiler to compute the size
of a VLA at compile time ;-)

Yeah, bloody C99! It came out of my mind.
 
D

Dan Pop

In said:
Yeah, bloody C99! It came out of my mind.

Even C89 doesn't guarantee that sizeof is computed at compile time.
It merely requires that it is computable at compile time, which is not
the same thing!

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top