Date: Mon, 2 Dec 2013 14:38:23 +0000 (UTC) From: jb <jb.1234abcd@gmail.com> To: freebsd-current@freebsd.org Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <loom.20131202T150023-793@post.gmane.org> References: <CA%2BhQ2%2BgK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com> <loom.20131130T002152-608@post.gmane.org> <CA%2BhQ2%2Bj0cYW0dfhEtMGRXWhXhS=VF_N_ZB=JmcqRUofFKWXFiQ@mail.gmail.com> <loom.20131130T012034-966@post.gmane.org> <CA%2BhQ2%2BiCjnxUMP0v6d5ez=n07MBT5hLXzoa%2B1wTff3Wrtm=SHQ@mail.gmail.com> <52995C15.7010903@gmx.com> <loom.20131202T132813-715@post.gmane.org> <CA%2BhQ2%2BhpH6up0duVRBbY8LXmwg_nGaj5qgeDSaw1EGqVpiUsxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo <rizzo <at> iet.unipi.it> writes: > ... > > So far, the options could be as follows: > > - realloc_flags(p, s, option) > > where option is one or a combination (where appropriate) of: > > REALLOCF_ANY - default (move or no-move; regular > > realloc()) > > REALLOCF_NO_MOVE - no-move > > REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE > > REALLOCF_FORCE - combined with REALLOCF_NO_MOVE > > REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its > > derivatives like REALLOCF_ELASTIC, etc > > > > just five ? for a (quote) "clean, safe and maintainable API", > I'd probably also add a few more, such as > REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code, > REALLOCF_I_AM_FEELING_LUCKY for the newbies, and > REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC > for skilled folks. > ... These are more or less part of current implementation of realloc() :-) But seriously, the new API takes advantage of current logic - the no-move is already implemented as part of default. It will not (and should not) interfere with current implementation-specific details; it will just be smarter and useful thru its options by asking specific requests, some of which could be already be partially satisified now (think of that extra, unused allocated space, if present), thus giving a programmer more power in one call. Adding some if-else logic and perhaps limited code restructuring will yield a really powerful, functional API. Some of the hidden bugs in current realloc() & co, if any, will be discovered during testing of new implementation (which will be more specific and thus less forgiving). Think of it as being presented with a chance to become part of history, as a co-creator of a new-and-improved memory management function, admittedly being many OS' and libraries' Achilles' heel :-) jb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20131202T150023-793>