Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Dec 2019 21:50:51 +0100
From: Szabolcs Nagy <>
Subject: Re: max_align_t mess on i386

* Alexander Monakov <> [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

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.