|
Message-ID: <20191215205051.GX23985@port70.net> Date: Sun, 15 Dec 2019 21:50:51 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: max_align_t mess on i386 * Alexander Monakov <amonakov@...ras.ru> [2019-12-15 23:03:08 +0300]: > On Sun, 15 Dec 2019, Rich Felker wrote: > > > > It might violate the standard technically speaking, but I don't know of > > > any examples of types smaller than 16 bytes that require 16 byte > > > alignment. > > > > It doesn't since no object can have size smaller than its alignment. > > (As long as pointer types aren't lossy; if some pointer types lost low > > bits, then it would be non-conforming.) > > Yeah. I believe one usual concern is whether low bits may be expected to be > zero in case one wants to carry a couple of bits along with the pointer. > > On one hand, C doesn't say what it means for an arbitrary pointer to be > suitably aligned for a particular type. On the other hand, in practice > everyone assumes that it means that its value is divisible by alignment, > and so on platforms with _Alignof(max_align_t) == 16, it means that low 4 bits > of any address returned from malloc (including those with tiny allocated > storage) will be zero. Which makes those bit positions available for flags > associated with the pointer, if you can arrange for them to be masked off > to use the pointer itself. > > (in principle a compiler could transform a program like that too, and unlike > a programmer the compiler knows exactly what it means for a pointer to be > aligned) > > So if such use is accepted as valid, malloc needs to ensure alignment despite > a small allocation size. i think iso c is unclear, but that will change in c2x which allows small alignment for small objects http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.