struct and union alignment

[CBFalconer]

Because vp holds an address which is not aligned for type int.

No. Because the conversion pointertype->void*type->pointertype is
only valid when the two pointertypes are identical.

 

[S.Tobias]

No. Because the conversion pointertype->void*type->pointertype is
only valid when the two pointertypes are identical.

Would you please explain why? You have drawn two conversions; which
one do you refer to?

 

[S.Tobias]

N869
6.3.2.3 Pointers
[#7] A pointer to an object or incomplete type may be
converted to a pointer to a different object or incomplete
type. If the resulting pointer is not correctly aligned
for the pointed-to type, the behavior is undefined.
N869
6.3.2.3 Pointers
[#1] A pointer to void may be converted to or from a pointer
to any incomplete or object type. A pointer to any
incomplete or object type may be converted to a pointer to
void and back again; the result shall compare equal to the
original pointer.

1. Why do you think that #7 does not apply this time?

Because the standard says so: character and void pointer values have

And [...] blessed are they that have not seen, and yet have believed!

no alignment restrictions. Therefore, when converting something to
pointer to void, the resulting value is, by definition, correctly aligned.

This is not an answer to my question! I didn't ask about the validity
of conversions nor alignment restrictions!

[ Please don't dismiss my questions with silly answers. I have come
here to learn something, not to turn the world upside-down.
This discussion costs me a lot of effort. I wish I had never started
it, but since I have, I feel obliged to defend my hypothesis as much
as reasonable. It might be proved wrong in the end, but I want to be
convinced by a fair argument. ]

It does. But #7 applies too.

This is what I claim, too.

There is no contradiction between the two.
#1 says that you can do the conversion and #7 says what happens if the
original pointer value was not properly aligned for the type of the result

[ ^^^^^^^^ strictly, it talks about resulting pointer,
but it might be the same as original]

of the conversion.

#1 talks about (void*)<->(any*) conversions, #7 talks about
(any*)<->(any*) conversions and adds alignment provisions.
#7 does not exclude *any* pointer type.

If #1 applies to (void*)<->(int*), then #7 applies just as well.

In question 1. I asked pete, why #7 should not apply to (int*)->(void*),
because he seemed to avoid this point in justifying such conversion
(he only cited #1 for this).
I still have not got an answer. I think #7 does apply, too.

The rest of the standard.

Would you please be so kind to give some pointers for an example.

Note: in above question I implicitly asked how you choose the rules #1
and #7 exclusively to apply to (void*)<->(int*) conversions, and such an
answer I expect. By no means was it a general question. Since you have
said that both #1 and #7 apply to (void*)->(int*), then the remaining
question is why we can't apply #7 to (int*)->(void*) and where does the
Standard say so; if that's the case of course - else I would like someone
to explicitly say that it applies too.

Unfortunately, the standard is very poorly
written as a reference document: you can't only read the paragraph(s)
of immediate interest and expect to get a complete picture of the issue.

It's true that I have little experience with the Standard, but I'm
learning. I hope you don't expect me to defend my arguments with
K&R2 only, when everybody else is holding the Standard in their hands.
I don't treat it as a reference, I have taken my knowledge from other
books and sources. I have searched (and still do) the whole of Standard
at different places. The discussion has concentrated on very narrow
questions. If you have the knowledge and can point to places in the
Standard to back up one argument or other, please share it with others.

 

[Dan Pop]

Would you please be so kind to give some pointers for an example.

Read the whole standard. If you still need the pointers, I will give
them to you.

If you want to lose your time by reading only random paragraphs, that's
fine, but this is not a reason for wasting my time, too.

Dan

 

[Dan Pop]

I took the first plausible definition I found. C++ is not topical here,
but C++ shares many ideas with C. I thought the definition in above
document was not C++ specific. Anonymous structures aren't topical
here either. I was casually interested, since someone mentioned them.
I think the above example you provided is called "unnamed structure".

Care to elaborate on the semantical differences between "anonymous" and
"unnamed"?

Dan

 

[S.Tobias]

Read the whole standard. If you still need the pointers, I will give
them to you.

I don't understand why to answer the simple question: if #7 is applicable
for (int*)->(void*) conversion, I have to read the whole Standard.
It requires only basic intelligence and comprehension.

If you want to lose your time by reading only random paragraphs, that's

"Random" is too much said. I read chapters of most interest to me.
Additionally, I follow the references and search the whole Standard
for things I want to find. I plan to read the Standard from cover
to cover one day, but it'll take some time.

fine, but this is not a reason for wasting my time, too.

I'm not wasting *your* time in *your* newsgroup!

I didn't ask specifically you to answer my posts. You have broken
into the middle of a discussion and deviated it into direction
I didn't want. You have not answered my questions (with exception
perhaps for one issue). I think you're being rude to me this way.
You have been rude at the start of this thread, and I haven't yet
seen your explanation there yet. If you think I'm not worthy
to share in your knowledge and waste your oh so precious time, please
stop reading answering my posts - I won't be sorry about that.

 

[Dan Pop]

I don't understand why to answer the simple question: if #7 is applicable
for (int*)->(void*) conversion, I have to read the whole Standard.
It requires only basic intelligence and comprehension.

Then, use them instead of reading the standard and see how far you go.

I gave a *complete* answer to your questions, in a previous post. You
didn't get it either because you're a complete idiot (which doesn't appear
to be the case) or because you're not familiar with the basics of the C
standard. Such familiarity cannot be achieved without reading the
standard.

I could waste some time and spot all the paragraphs you need in order to
understand this issue and spoon feed them to you, but I see no point in
doing it.

Dan

 

[Dave Thompson]

Wrong. Both the struct and union have the same
alignment as double. A struct's alignment is
the same as the strictest (widest) alignment
of any of its members, including nested aggregates.
Same rules apply for union. The alignment is that
of the strictest alignment of any of its members,
including nested aggregates (other unions or
structs).

That's the common and sensible implementation, but not required. It is
necessary that a struct or union (type) be sufficiently aligned for
each of its members, and never AFAICS necessary to be more, but
nothing prohibits more if an implementor wants it for some reason.

- David.Thompson1 at worldnet.att.net