On 1/3/06, Jim Jagielski wrote: > Garrett Rooney wrote: > > > > On 1/2/06, jim@apache.org wrote: > > > Author: jim > > > Date: Mon Jan 2 08:52:58 2006 > > > New Revision: 365376 > > > > > > URL: http://svn.apache.org/viewcvs?rev=3D365376&view=3Drev > > > Log: > > > Avoid magic numbers. Since we are reading the header, let's > > > be explicit about it. Also removes the need to clean up > > > the readbuf again, and any potential for confusion on > > > what we are doing ;) > > > > Um, doesn't this assume that there's no padding in the compiler's > > layout of the struct? Is that safe to do? I've always been under the > > impression that relying on such things is not portable. If nothing > > else we should probably have a compile time check that it's size =3D=3D 8, > > or something... > > > > I'm fine with removing the use of sizeof and sticking with '8', since > it's a defined value in the FCGI protocol itself. But we use sizeof > header in loads of other places there as well... The problem isn't just the number of bytes we read off the wire, it's also that if the compiler has introduced padding between elements of the struct when you recv directly into the struct the data is not aligned with the proper members, so when you later access it you get the wrong values. As for other places we're using sizeof(header), I didn't write those places, so I can't be sure without some more investigation, but they've potentially got the same problem. -garrett