size of a struct without "sizeof"

S

Stephen Sprunk

Eric said:
By happenstance, by chance, by pure dumb luck. If you
wear a blindfold while driving a car, it is possible that
your journey will be uneventful.

While I understand what you're trying to express here, I wouldn't chalk
it up to happenstance. C is most easily implemented on a system with a
flat memory space, a stack, a heap, all-zeros null pointers, etc. Most
systems, in turn, are defined these days by their creators in terms of
how to implement C on them, which leads to designing them in ways that
make C easy to implement. So, it's not chance that most systems look
fairly similar and certain common tricks, while not defined by the
Standard, happen to work on those systems.

Systems which were designed around other languages, like FORTRAN or
COBOL or Java, will look entirely different -- but with the vast
majority of code these days being in C or languages designed to be
compatible with C, they're not so popular.

S
 
K

Keith Thompson

pete said:
Keith said:
struct whatever array[2];
unsigned char *first = (unsigned char *)&array[0];
unsigned char *second = (unsigned char *)&array[1];

printf("%d\n", (int)(second - first));
Converting the ptrdiff_t result of the subtraction to int is
unnecessary. It's possible (if unlikely) that sizeof(struct whatever)
could exceed INT_MAX.

Shouldn't the possibility that sizeof(struct whatever)
could exceed INT_MAX,
be the reason why converting the ptrdiff_t result
of the subtraction to int is *necessary*?

Not at all. The conversion is necessary in this context because int
and ptrdiff_t aren't necessarily compatible types.

It's possible that ptrdiff_t could be a typedef for short (though I
know of no real-world system where this is the case). On such a
system (or on any system where ptrdiff_t is a typedef for something
other than int), this:
printf("%d\n", second - first);
invokes undefined behavior.

(As I explained elsethread, what I meant to say (and utterly failed to
say clearly) is that the cast isn't necessary to compute the size; it
is necessary to print it, unless you have the size expressed in a type
for which printf has a format.)
 
R

Richard Tobin

Keith Thompson said:
It's possible that ptrdiff_t could be a typedef for short (though I
know of no real-world system where this is the case). On such a
system (or on any system where ptrdiff_t is a typedef for something
other than int), this:
printf("%d\n", second - first);
invokes undefined behavior.

Surely the short will have been promoted to an int.

-- Richard
 
D

Default User

srikar2097 said:
Are you sure the METHOD 1 given by me does not work?

I ran the program and got the size as 8bytes.
Then I ran the program using the sizeof() and got the size as 8
bytes.

Is this a coincidence? This method works. If in doubt you could try it
yourself.

There is no defined behavior for undefined behavior. That means it can
seem to do what you want. Today. Maybe not tomorrow. Maybe not with a
different compiler.




Brian
 

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,982
Messages
2,570,186
Members
46,744
Latest member
CortneyMcK

Latest Threads

Top