David Brownell <[EMAIL PROTECTED]> writes: > On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote: >> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]> >> wrote: >> >> > [btw, I truly have little idea about which are those specific costs, >> > out of professional curiosity, got any pointers?] >> >> http://www.digitalvampire.org/blog/articles/2006/07/31/why-you-shouldnt-use-__attribute__-packed > > In fact the executive summary on that page applies nicely: > > "don’t add __attribute__((packed)) to your code unless > you know you need it."
I'd add "and if you think you do, reconsider your design" ;) This attribute is IMHO only really useful to simplify porting of some badly designed code to GCC. > > My point [b] explained why/how "we know we need it". You seem > to have ignored that part of the discussion this time, just like > the last several times it's come up. For me __attribute__((packed)) is somewhat similar to 'volatile'. Whenever I see it, I think: "Care! Something is probably wrong with the code". In case of 'packed', probably alignment and/or endianness is not handled in a portable manner, and in case of 'volatile' probably some barriers are missing. Finally, proponents of volatile also believe they know they need it (no offence intended), while in fact they don't (in most cases). IMHO, the truth is that one just can't express what is on wire with bare C struct (the same way one can't express all the required constraints with 'volatile'), and 'packed', being a weak attempt to achieve this goal, should be avoided in general. More so as it brings more problems than it solves. -- Sergei. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
