On Wed, 15 Nov 2006 00:08:45 -0800 Rao Shoaib <[EMAIL PROTECTED]> wrote:
> Michael Hunter wrote: > >>>388,1123,1272,1323,1379,1420,1456: Whats the need for these uses of > >>>pragma pack? Under what circumstances have you shown they are needed? > >>>Its esp. concerning given the comment above and the first structure > >>>leading off with a bunch of bare 'int's. > >>Running a 32-bit userland application (e.g., snmp agent) on an amd64 > >>system. The size of the structure returned by the kernel would then > >>possibly be larger than what the user application is expecting, which > >>could cause it to break. > Michael, > > I also thought that using the pragma is not necessary. However now that > I have looked into solving the issue I am not so sure. > > The issue we are trying to resolve can not be solved by using types > defined by size. Specifically we are using int64_t. On Solaris both 32 > and 64 bit this is 8 byte aligned and there are no issues. On X86 it is > 4 byte aligned for 32 and 8 byte for 64 bits and that is where the > problem comes in. The documentation says int64_t is 4 byte aligned for > X86 but 8 bytes is a multiple of 4 and so I guess the compiler is not at > fault. > > The options to solve this issue are > > *) Hand construct the structure with proper padding. This could break if > someone changes anything in the struct. > > *) Use STRUCT_DECL(9F) and copy each field. These two are the same in that they are field by field mechanisms for making sure the layout of each field is correct. The second is probably less error prone over the long haul as its more explicit. The first is easier in the short term. > > *) Use the pragma and force the alignment. > > The last option looks pretty clean and (easy :-)) and is already being > used by SCTP so I think it should be OK for Anders to use as well. I disagree with the reasoning that since another part of the codebase does something its ok to do. If the practice in question is valid then there should be an argument from first principles that supports it. Also the scenario it was used under was one in which the code already existed and a port needed to be done. That isn't the same situation you are currently in. > > >ANSI doesn't guarantee that #pragma means anything. Can't you used types > >defined by size to achieve this goal? > > > > > ANSI may not gaurantee that #pragma means anything but Sun compilers do > and these pragmas are documented so it should be legal to use them. in > fact sun documentation says to us ethese pragmas. As others have noted this isn't an argument for using a language option. We currently also use gcc and could (ok, unlikely) use another compiler in the future. > > >I think the following thread lays out why I don't think you should use > >pragma pack. > > > >https://www.opensolaris.org/jive/thread.jspa?messageID=64062慨 > > > > > I am not sure if this thread completely applies to this issue. However > even in the thread folks have cited cases where it would be legal to use > pragmas. I think the thread is relevant. I also agree that there are places where using pragma pack makes sense. I don't think this is your best choice here. But I also don't see a viable option that doesn't stink much less given the extra labor you will have to go through at this point. I'll hold my nose I guess :( I wouldn't mind ya'all documenting the actual issue. The ifdef's hint pretty strongly at the situation under which you are using pragma pack. Just make that explicit above the first use. > > I hope you will let us use the pragma till we find a cleaner generic > solution and fix all users such as SCTP. > > Thanks again for taking the time to review this code. Not a problem. mph > > Rao. > > > mph > > > > > > > _______________________________________________ networking-discuss mailing list [email protected]
