Hi Everyone!
I have written a code for it,it gives 2 warning messages but still gives the right answer.Can you share better ideas to implement for this concept.
Tryin to store address in int var is the warning,but when I try to use pointers and implement,the difference between the addresses i given as 1 and not 8.Code:#include<stdio.h> union size { int i; double d; }u[1]; int main() { int res,a,b; a=u+0; b=u+1; res=b-a; printf("size of union=%d\n",res); return 0; }
How about
int *a = &u[0].i;
int *b = &u[1].i;
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Tried what you written,but's it's giving an answer as 2 instead of the 8.Originally Posted by Salem
You should typecast a and b to int. Then you'll get answer as eight.
Code:a=&u[0].i; b=&u[1].i; res=((int)b-(int)a);
Even though this is a mostly pointless exercise, I think it would be better to cast the pointer to a pointer to char, not to int (int may not be big enough to hold a pointer, ie, sizeof(int) < sizeof(char *)):
And you can obviously do the same without the intermediate variables "a" and "b":Code:char *a = (char *)&u[0]; char *b = (char *)&u[1]; int res = b - a;
Code:int res = (char *)&u[1] - (char *)&u[0];
As long as you do only pointer arithmetic with the unions it should be safe.
But otherwise you should have at least 2 instances of the union
like
KurtCode:union size { int i; double d; }u[ 2 ];
Actually, u[1] is sufficient.
It is legal to have a pointer to the first element off the end of an array - but you can't dereference it.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
That's what I was trying to say.
This exercise is pointless, since the compiler could not evaluate &u[0] and &u[1] (or &u[0].i and &u[0].i) without its own built-in knowledge of the value of sizeof(u). Not using the sizeof() keyword in code does not mean you are not making use of sizeof().
Better to make the pointers of type char * rather than int, and use a type conversion to char *. No need to reference members of the union either. &u[0] is enough.
When evaluating the difference between two pointers, better to use ptrdiff_t to get the difference. Then, if you must, convert that ptrdiff_t to another integral type for printing (printf()'s format modifiers to print a ptrdiff_t were not aware of ptrdiff_t in earlier versions of C). Less chance of overflowing an int that way, particularly on systems with pointers that are larger than an int.
Then again, the size of the union in the example will (should?) always fit in an int, regardless of the size of pointers compared to the size of int, so storing the difference between pointers in an int variable (and printing that int) is fine in this case, IMO. But in the general case, ptrdiff_t is preferred over int.
Yeah, right. Only if you believe that all unions are small, like in the original example. It is very easy to construct a union (say, with one of its members is a large struct) that will produce a difference that cannot be represented by an int.
It gives you a 1 when you use pointers because when you do pointer arithmetic, it gives you results in units of the type size, not the size in bytes. which makes sense, because if you used pointers instead of ints for a and b,
and you assign a = u+0 and b = u+1, and then subtract b-a, you get back what you added which is 1, not 8. it wouldn't make sense to if (u+1)-(u+0) == 8.
as several folks said, casting to char * will give you the difference in bytes.
I don't see what the problem is - "ptrdiff_t" is designed to hold a value equal to the difference between two pointers (the very thing that is trying to be achieved)
It was created because "Existing types were deemed insufficient, because their size is defined according to the target processor's arithmetic capabilities, not the memory capabilities, such as available address space..."
You seem to be quoting someone or something, but you haven't given your source. I'm assuming it's the Standard or the Rationale, but you should say so. Giving a link (if possible) is helpful, too.
Question: If you want to print out a ptrdiff_t, what type do you cast it to? I assume a long. But if it is guaranteed to always fit into a long, what's the point of ptrdiff_t?
The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss
The problem is that some people insist on using int for such things, on the basis of something like "it works for this example, with my compiler". They then duck and weave (or simply refuse to respond) if someone uses their approach in a way that doesn't work.
After all, an approach that works for some cases is just as good as an approach that works for all cases (within compiler limits) right?
