Replace use of obsolete memalign function with posix_memalign
The following description in the memalign man page provides some very good reasons to justify replacing all the use of memalign with posix_memalign:
On many systems there are alignment restrictions, for example, on buffers used for direct block device I/O. POSIX specifies the pathconf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is needed. Now one can use posix_memalign() to satisfy this requirement.
posix_memalign() verifies that alignment matches the requirements detailed above. memalign() may not check that the boundary argument is correct.
POSIX requires that memory obtained from posix_memalign() can be freed using free(3). Some systems provide no way to reclaim memory allocated with memalign() or valloc() (because one can only pass to free(3) a pointer gotten from malloc(3), while, for example, memalign() would call malloc(3) and then align the obtained value). The glibc implementation allows memory obtained from any of these three routines to be reclaimed with free(3).
The glibc malloc(3) always returns 8-byte aligned memory addresses, so these routines are only needed if you require larger alignment values.
#2 Updated by Michael Robson over 4 years ago
- % Done changed from 0 to 10
- Status changed from New to In Progress
I generated a list of locations to fix with the following command in charm/src: grep -nr memalign * | grep -v posix
I was going to post the results here but it's a fairly long list. Let me know if any of these are incorrect.
Also, posix_memalign returns an error code instead of the pointer (that's now an argument). I'm unsure on the general Charm++ philosophy on error codes for system functions. Should I wrap error checking in CMK_DEBUG flags (or something similar, I'm not sure what the default is and this is just a guess)?
#5 Updated by Dong Hun Lee over 2 years ago
- Status changed from New to Rejected
- translation missing: en.field_closed_date set to 2017-02-06 17:11:43.012578
There is a primary concern of whether posix_memalign would be portable, and the usage of memalign for the linux builds are considered to be obscure and very narrow case to see the benefit of replacing.
After consulting with Michael and Phil, it was suggested to be rejected.