Date: Mon, 2 Dec 2013 05:29:06 -0800 From: Luigi Rizzo <rizzo@iet.unipi.it> To: jb <jb.1234abcd@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <CA%2BhQ2%2BhpH6up0duVRBbY8LXmwg_nGaj5qgeDSaw1EGqVpiUsxw@mail.gmail.com> In-Reply-To: <loom.20131202T132813-715@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 2, 2013 at 4:36 AM, jb <jb.1234abcd@gmail.com> wrote: > <dt71 <at> gmx.com> writes: > > > > > So new flags could be [1]: > > - realloc_flags(p, s, REALLOCF_NO_MOVE) > > ... > > - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC) > > ... > > For this, there could be a REALLOCF_FORCE flag > > In case of realloc_flags() failing the request, to avoid unnecessary > followups with regular realloc() when desired, we should include an option > like REALLOCF_FALLBACK_ANY that would allow to fallback on the regular > realloc() logic, in one call. > > In addition, because I have an impression that realloc_flags() may have > a future as a replacement for regular realloc() and we should aim for it, > we should include an option like REALLOCF_ANY for that purpose. > > 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. I am not sure they are enough to cover the spectrum of possible options, but there are at least 32 bits in the flags so we have a few more left. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BhpH6up0duVRBbY8LXmwg_nGaj5qgeDSaw1EGqVpiUsxw>