Re: max_align_t mess on i386

[Szabolcs Nagy <nsz@port70.net>]

* Alexander Monakov <amonakov@ispras.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