Date: Sun, 15 Dec 2019 23:03:08 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: max_align_t mess on i386 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. Alexander
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.