> Frank Hofmann wrote: > > Hi, > > > > I'm looking for a generic opinion on the use of "#pragma pack" for > > writing Solaris code. I know it's useful for device register sets, or > > data structures that don't follow ABI layout rules. > > > > We use #pragma pack(4) at a few places in Solaris (for example, the > > SVM on-disk layout data structures on Solaris/x86). > > > > Should such a use be allowed or discouraged for new code ? I.e. if I > > have a data structure that is packed (no padding, contains misaligned > > multibyte entities), should I better write a convertor function or > > were it ok to use #pragma pack(1) ? > > > > Thanks, > > FrankH. > > _______________________________________________ > > opensolaris-code mailing list > > [email protected] > > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code > > I have mixed opinions about this. > > Personally, for most of the cases where you are interfacing with > devices, I think the ddi accessor functions is best. > > However, for certain use cases -- like network protocols and on-disk > formats, I think packing is completely reasonable. In those cases, be > certain you use intXX_t, e.g. int32_t, uint16_t, etc. rather than > relying on the size of native data types. > > Of course, I don't work for Sun, and I don't speak for Solaris. But its > just my opinion.
Basically the rule of thumb here is do not use this. Do not rely on misaligned accesses for new code. As is mentioned above, if you're trying to achieve packing for an on-disk or over-the-wire format you should be using the fixed-size integer typedefs and manually arranging them appropriately. The only exception to this rule is when you're dealing with an extant structure, typically on x86 only, which is defined to behave this way and you can't change it (i.e. defined by someone outside of the OpenSolaris community and new engineering work). For example, when I wrote the SMBIOS stack for Solaris the format itself as defined by the spec requires packing of this variety, so there's really little else to do. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
