Re: Endless loop in split_on_bdry() of library/parser_multipart.c?

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