3 ms·
There was no actual dereferencing, this is just pointer arithmetic. it's "line6 = podhd + offset". There isn't really a better way to do it.
by ploxiln 12y ago
There was no actual dereferencing, this is just pointer arithmetic. it's "line6 = podhd + offset". There isn't really a better way to do it.
- ehmmm 12y agoThere is no pointer arithmetic in the line: struct usb_line6 *line6 = &podhd->line6; Offset is calculated "below the hood". Pointer arithmetic is defined with arithmetic operands: +,- -> and . are not arithmetic operands.
- jwatte 12y agoYou sound very sure of yourself. If you look at the definition of the -> and [], you might learn something!
- ehmmm 12y agoClearly, you don't have anything constructive to say, so you have to resort to ad hominem. [] operator doesn't have any place in this debate.
- spoiler 12y agoWell, as far as I understand it, `->` works in a similar fashion to `[]`; the difference being that one behaves on arrays while the other on structs. What @jwatte tried to say is that `->` works like this: // foo is struct thingity* &foo->bar == foo + offsetof(struct thingity, bar); The `[]` does a similar thing: // s is char* *(s+i) == s[i]
- ehmmm 12y agoSure, &foo->bar looks like foo + offsetof(struct thingity, bar), but there is no pointer arithmetic involved since C doesn't specify how the member access ( -> or . ) is actually calculated. It does however specify that [] operator is equivalent to pointer arithmetic. But we are talking ->,. operators and not [].
- kstenerud 12y agoMost underlying implementations won't actually dereference here (which is why it usually works), but as far as the spec is concerned, you are dereferencing it, which is undefined. That becomes a problem with modern optimizing compilers, because they make assumptions about your code based on what's allowed according to the spec.