> Date: Wed, 05 Jul 2023 07:03:09 -0400 > From: Greg Troxel <g...@lexort.com> > References: <20230705105858.33080f...@cvs.netbsd.org> > > "Taylor R Campbell" <riastr...@netbsd.org> writes: > > > Revert "newfs(8): Ensure A divides S before aligned_alloc(A, S)." > > > > C17 lifted this restriction. > > I know we have only two toolchains maintained in tree, but did we really > decide to require C17?
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!