> Mark Mitchell wrote:
> >
> > struct A {...};
> > struct B { ...; struct A a; ...; };
> >
> >
> > void f() {
> >B b;
> >g(&b.a);
> > }
> >
> >
> >does the compiler have to assume that "g" may access the parts of
> >"b" outside of "a". If the compiler can see the body of "g" tha
On May 17, 2005, at 4:00 PM, Mark Mitchell wrote:
it is that whether or not you spell "8" as "8", "&s.x - &s.y", or
"offsetof (S, x) - offsetof (S, y)" should not matter, in which
case I certainly agree.
Yes, that is it, we agree.
Mike Stump wrote:
We need to teach it about the meaning of constants.
One can:
#include "foo.h"
main() {
printf ("%d\n", offsetof (s, m));
}
and then in another file, read and use that on an address. One can
also transform it into a #define S_M_OFFSET 8, and #include it. So,
I'd claim the
On May 17, 2005, at 2:21 PM, Mark Mitchell wrote:
It wouldn't look like escape to (at least some compilers')
optimizers if, say, the front end folded it to a constant. So, I'm
not sure how to express what constitutes escape.
Well, we're going to need to ensure the optimizer can see various
t
Nathan Sidwell wrote:
Mark Mitchell wrote:
Will the UK committee open a DR for this? Or, would you care to send
mail to Steve Adamczyk about it?
this can be done. I shall wait until the minutes have been written up.
Excellent.
The observation was made that if A is non-POD, one cannot play offset
Mark Mitchell wrote:
> Will the UK committee open a DR for this? Or, would you care to send
> mail to Steve Adamczyk about it?
this can be done. I shall wait until the minutes have been written up.
>
>> The observation was made that if A is non-POD, one cannot play offsetof
>> tricks to get fr
Nathan Sidwell wrote:
I attended a UK C++ panel meeting yesterday, and took the opportunity
to solicit opinions on this. The question I posed was
struct A {
...
T1 a;
T2 b;
};
void g(T1 &a);
void Foo () {
A v;
v.b = 2;
g (v.a);
Mark Mitchell wrote:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(&b.a);
}
does the compiler have to assume that "g" may access the parts of "b"
outside of "a". If the compiler can see the body of "g" than it may be
able to figure out that it can't access
On May 12, 2005, at 4:32 AM, Theodore Papadopoulo wrote:
Is the compiler allowed to suppress b2 and/or b3 from the layout of
the
object.
Yes, of course, in some cases. For example when whole program
analysis tells it, it can.
The next question comes when b1,b2 and b3 are in various places
in
On Thu, 2005-05-12 at 10:01 -0700, Mark Mitchell wrote:
> Theodore Papadopoulo wrote:
> > On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> >
> > Given the following:
> >
> > struct A {
> > B& b1;
> > B& b2;
> > const B& b3;
> >
> > A(B& b): b1(b),b2(b),b3(b) { }
> > };
>
Theodore Papadopoulo wrote:
On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
Given the following:
struct A {
B& b1;
B& b2;
const B& b3;
A(B& b): b1(b),b2(b),b3(b) { }
};
Is the compiler allowed to suppress b2 and/or b3 from the layout of the
object. The next question come
On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> Wolfgang Bangerth wrote:
> > Mark,
> > it occurred to me that asking the question you pose may use language that
> > is
> > more unfamiliar than necessary. How about this question instead -- assume
> >
> > struct S { int s; };
> > str
Wolfgang Bangerth wrote:
Mark,
it occurred to me that asking the question you pose may use language that is
more unfamiliar than necessary. How about this question instead -- assume
struct S { int s; };
struct X {
int i;
struct S s;
};
void g(struct S*);
void f() {
X x;
The attribute might well be unnecessary, and once it's in it's in forever.
And I suspect supporting
different semantics for different calls will create problems down the line,
somehow or other
(although I confess I don't think of any offhand).
Attributes and flags have more or less the same effec
Our proposed approach is to -- by default -- assume that "g" may access all
of "b". However, in the event that the corresponding parameter to "g" has an
attribute (name TBD, possibly the same as the one that appears in Danny's
recent patch), then we may assume that "g" (and its callees) do not
Mark,
it occurred to me that asking the question you pose may use language that is
more unfamiliar than necessary. How about this question instead -- assume
struct S { int s; };
struct X {
int i;
struct S s;
};
void g(struct S*);
void f() {
X x;
g(&x.s);
}
Would the
Bernd Jendrissek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
no obvious answer.
May I bash my head against the wall? :)
Sure, it's a free world!
The struct declaration places an obligation on the compiler to provide
an *extern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
> no obvious answer.
May I bash my head against the wall? :)
> In short, the issue is, when given the following code:
>
> struct A {...};
> struct B { ...; struct A a; ...; };
Telli
On May 11, 2005, at 2:42 PM, Mark Mitchell wrote:
Our proposed approach is to -- by default -- assume that "g" may
access all of "b". However, in the event that the corresponding
parameter to "g" has an attribute (name TBD, possibly the same as the
one that appears in Danny's recent patch), the
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
Our proposed approach is to -- by default -- assume that "g" may
access all of "b". However, in the event that the corresponding parameter to
"g" has an attribute (name TBD, possibly the same as the one that
appears in Danny's recent p
On May 11, 2005, at 11:42 AM, Mark Mitchell wrote:
Kenny and I had a long conversation about the aliasing issue, and
reached the following proposed solution.
In short, the issue is, when given the following code:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Our proposed approach is to -- by default -- assume that "g" may
> access all of "b". However, in the event that the corresponding parameter to
> "g" has an attribute (name TBD, possibly the same as the one that
> appears in Danny's recent patch), then w
Wolfgang Bangerth wrote:
I understand that you are talking about ISO C, but one relevant case (in C++)
to look out for that is similar is this one, which certainly constitutes
legitimate and widespread use of language features:
class A {...};
class B : public A { ... };
void f() {
B b;
> In short, the issue is, when given the following code:
>
>
> struct A {...};
> struct B { ...; struct A a; ...; };
>
>
> void f() {
>B b;
>g(&b.a);
> }
>
> does the compiler have to assume that "g" may access the parts of "b"
> outside of "a".
I understand that you are talking
Kenny and I had a long conversation about the aliasing issue, and
reached the following proposed solution.
In short, the issue is, when given the following code:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(&b.a);
}
does the compiler have to assume that "g
25 matches
Mail list logo
