Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> writes:
> Well, what happened is: > > 1. I was drafting posix_memalign and aligned_alloc for libbsdmalloc in > response to the thread about static program size yesterday, and > carefully reading the specs -- POSIX 2018, C11 -- to make sure I > got all the details right. > > 2. I saw a silly restriction in C11, that aligned_alloc(A, S) requires > A to divide S. > > 3. For the sake of encouraging portable code, I figured we should > enforce that restriction, so I went ahead and did that in both the > libbsdmalloc front end I was writing and in jemalloc. (This caused > a bunch of tests to start failing.) > > 4. I audited all the uses of aligned_alloc in tree to make sury they > meet the restriction (which fixed the tests). > > 5. Someone pointed out that the silly restriction that was imposed in > C11 had actually been lifted in C17: > > (C11) The value of alignment shall be a valid alignment > supported by the implementation and the value of size shall be > an integral multiple of alignment. > > (C17) If the value of alignment is not a valid alignment > supported by the implementation the function shall fail by > returning a null pointer. > > 6. So I reverted the jemalloc enforcement of the C11 restriction, and > reverted the fixes made to conform to it, and removed the > restriction in the new libbsdmalloc code, and we're more or less > back to where we started. > > Except I am now reminded that I updated t_posix_memalign.c to verify > this silly restriction of aligned_alloc, so I'd better go fix that > before a bunch of tests start failing again! Thanks for taking the time to explain so thoroughly. So we are back to status quo ante-fixum, which is by definition always ok :-)