Quoting Bojan Smojver <[EMAIL PROTECTED]>:
I can test the above in my setup and see what comes out, but I'm more
worried about the incorrectly compiled code and why it happened. I'm not
sure if it's due to bugs in gcc, or is it something that RING/BRIGADE
macros are doing that really isn't quite right.
I just posted this to the RH bug report:
==========================================================
One thing seems strange in the intermediate code:
------------------------------
((long) (((char *) (&(((struct apr_bucket*)((void *)0))->link))) - ((char *)
((void *)0))))
------------------------------
The above code is most likely this from apr_general.h:
------------------------------
#define APR_OFFSET(p_type,field) \
((long) (((char *) (&(((p_type)NULL)->field))) - ((char *) NULL)))
------------------------------
I was under the impression that on Linux, there is offsetof that can be used.
So, I created a little test program:
------------------------------
#include <stdio.h>
#include <stddef.h>
int main(int argc,char **argv){
struct test{
int a;
char *b;
};
printf("%lu\n",offsetof(struct test,b));
return 0;
}
------------------------------
Compiled it:
------------------------------
gcc -Wall -save-temps -ansi -o test test.c
------------------------------
This give intermediate code:
------------------------------
int main(int argc,char **argv){
struct test{
int a;
char *b;
};
printf("%lu\n",__builtin_offsetof (struct test, b));
return 0;
}
------------------------------
Sooo, why isn't APR code using that instead? No idea...
BTW, the output of the program on an x86_64 box is 8.
==========================================================
Looks like the offsetof() provided by the platform isn't being used.
Which in turn causes a lot of casting all over the place, which
creates the aliasing problem? Maybe?
--
Bojan
