<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 jbReceived on Mon Dec 02 2013 - 11:36:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC