Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of bojan@rexursive.com designates
 203.171.74.242 as permitted sender)
Message-ID: <20060615153602.vd5hzssg84k4ws4k@www.rexursive.com>
Date: Thu, 15 Jun 2006 15:36:02 +1000
From: Bojan Smojver <bojan@rexursive.com>
To: apreq-dev@httpd.apache.org
Subject: Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
References: <1148955189.2956.132.camel@coyote.rexursive.com>
	<20060602125748.GA23447@redhat.com> <44829392.5060102@p6m7g8.com>
	<87r71v8bag.fsf@gemini.sunstarsys.com>
	<1150147748.3581.5.camel@coyote.rexursive.com>
In-Reply-To: <1150147748.3581.5.camel@coyote.rexursive.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.1)

Quoting Bojan Smojver <bojan@rexursive.com>:

> 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:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

Looks like the offsetof() provided by the platform isn't being used. =20
Which in turn causes a lot of casting all over the place, which =20
creates the aliasing problem? Maybe?

--=20
Bojan