On Tue, Aug 18, 2015 at 10:33:49AM +0200, Jan Tulak wrote: > On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote: > > > I thought about it. However, with memalign from malloc marked obsolete > > > (and with posix_memalign having guaranteed alignment restrictions [1]), I > > > saw it better > > > to use the posix variant everywhere. > > > > Putting a sane wrapper around an nasty library function is just > > fine. The memalign wrapper makes sense from this perspective - even > > gcc can't tell if variables passed to posix_memalign are correctly > > initialised or not, whereas no such problems exist for memalign(). > > > > > I could make a wrapper simulating the old memalign behaviour, but I don't > > > think it would make sense. > > > > I think it makes more sense than using posix_memalign() everywhere > > and then ignoring the return variable that tells you it failed... > > > > > I searched for this, but didn't find any reasonable answer: > > > How long can be things in standard libraries marked obsolete before > > > removing? > > > > With a wrapper, we don't care. > > > > > [1] man memalign: > > > On many systems there are alignment restrictions, for example, on > > buf- > > > fers used for direct block device I/O. POSIX specifies the > > path- > > > conf(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 alignment > > argument > > > is correct. > > > > Yes, you can get it wrong with memalign. But we don't, because we > > follow the rules for DIO buffer alignment and set it correctly. > > Being able to directly control the alignment of the memory buffer is > > a reason for using memalign() over posix_memalign(), not the other > > way around. > > > > So a wrapper used on all platforms is an acceptable solution? All right, > this explanation makes sense. I will change it that way. The only question > I have now is whether to use posix_memalign on every platform, or whether to > make it platform_memalign and use the old memalign inside for Linux. No need for a wrapper on platforms that support memalign. We can add a wrapper when and if memalign ever goes away (which, FWIW, will break lots of code). Indeed, we alreadyhave these platform dependent "wrappers": include/darwin.h:#define memalign(a,sz) valloc(sz) include/freebsd.h:#define memalign(a,sz) valloc(sz) The question now is - do we even need to change anything? https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html "The valloc() function allocates size bytes of memory and returns a pointer to the allocated memory. The allocated memory is aligned on a page boundary" Which means it does pretty exactly the same thing as posix_memalign(), and so we don't need to change anything, right? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
