Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Performance of unaligned memory-accesses Date: Wed, 07 Aug 2019 17:27:13 -0700 Organization: None to speak of Lines: 31 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="c2e3c649afb59b0d1215e9c099fa96fa"; logging-data="22146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/DYjtUV5i+gCUSnPWKHK7I" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:iAK7nZp5yRxQ8GtgZaIeJVnhOuo= sha1:6fIw9KVJ0bZjS1xnYIjLPcT9SC4= Xref: csiph.com comp.lang.c++:67412 David Brown writes: [...] > Compiler extensions like "packed" are fine in my book. Use them if they > make the code clearer and more efficient - assuming, of course, that the > lack of portability is not a problem. Compilers that don't support such > features will complain, so you don't get silent problems. Compiler extension like "packed" can cause problems. For example, suppose you have something like this (using gcc syntax): struct foo { char c; int i; } __attribute__((packed)); foo obj; some_func(&obj.i); some_func() takes an argument of type int*, but there's no indication that it's misaligned, so it can't take any special steps to avoid blowing up when it dereferences its argument. Recent versions of gcc and clang warn about taking the address of a misaligned member of a packed structure. https://stackoverflow.com/q/8568432/827263 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */