[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
