2008-04-28 21:44:54 +00:00
|
|
|
/*
|
2012-12-12 18:06:53 +00:00
|
|
|
* viralloc.c: safer memory allocation
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
2014-09-03 19:39:21 +00:00
|
|
|
* Copyright (C) 2010-2014 Red Hat, Inc.
|
2008-04-28 21:44:54 +00:00
|
|
|
* Copyright (C) 2008 Daniel P. Berrange
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2008-04-29 13:37:20 +00:00
|
|
|
#include <config.h>
|
2008-04-28 21:44:54 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
2012-12-12 18:06:53 +00:00
|
|
|
#include "viralloc.h"
|
2012-12-12 17:59:27 +00:00
|
|
|
#include "virlog.h"
|
2013-06-07 08:37:25 +00:00
|
|
|
#include "virerror.h"
|
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_NONE
|
2008-04-28 21:44:54 +00:00
|
|
|
|
2014-02-28 12:16:17 +00:00
|
|
|
VIR_LOG_INIT("util.alloc");
|
|
|
|
|
2008-05-29 15:13:07 +00:00
|
|
|
#if TEST_OOM
|
2014-10-28 18:38:04 +00:00
|
|
|
static int testMallocNext;
|
|
|
|
static int testMallocFailFirst;
|
|
|
|
static int testMallocFailLast;
|
|
|
|
static void (*testMallocHook)(int, void*);
|
|
|
|
static void *testMallocHookData;
|
2008-05-29 15:13:07 +00:00
|
|
|
|
|
|
|
void virAllocTestInit(void)
|
|
|
|
{
|
|
|
|
testMallocNext = 1;
|
|
|
|
testMallocFailFirst = 0;
|
|
|
|
testMallocFailLast = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int virAllocTestCount(void)
|
|
|
|
{
|
|
|
|
return testMallocNext - 1;
|
|
|
|
}
|
|
|
|
|
2008-05-29 18:47:00 +00:00
|
|
|
void virAllocTestHook(void (*func)(int, void*), void *data)
|
2008-05-29 15:13:07 +00:00
|
|
|
{
|
|
|
|
testMallocHook = func;
|
|
|
|
testMallocHookData = data;
|
|
|
|
}
|
|
|
|
|
|
|
|
void virAllocTestOOM(int n, int m)
|
|
|
|
{
|
|
|
|
testMallocNext = 1;
|
|
|
|
testMallocFailFirst = n;
|
|
|
|
testMallocFailLast = n + m - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int virAllocTestFail(void)
|
|
|
|
{
|
|
|
|
int fail = 0;
|
|
|
|
if (testMallocNext == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail =
|
|
|
|
testMallocNext >= testMallocFailFirst &&
|
|
|
|
testMallocNext <= testMallocFailLast;
|
|
|
|
|
|
|
|
if (fail && testMallocHook)
|
2008-05-29 18:47:00 +00:00
|
|
|
(testMallocHook)(testMallocNext, testMallocHookData);
|
2008-05-29 15:13:07 +00:00
|
|
|
|
|
|
|
testMallocNext++;
|
|
|
|
return fail;
|
|
|
|
}
|
2013-03-22 09:18:48 +00:00
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
void virAllocTestOOM(int n ATTRIBUTE_UNUSED,
|
|
|
|
int m ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
/* nada */
|
|
|
|
}
|
|
|
|
|
|
|
|
int virAllocTestCount(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void virAllocTestInit(void)
|
|
|
|
{
|
|
|
|
/* nada */
|
|
|
|
}
|
|
|
|
|
|
|
|
void virAllocTestHook(void (*func)(int, void*) ATTRIBUTE_UNUSED,
|
|
|
|
void *data ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
/* nada */
|
|
|
|
}
|
2008-05-29 15:13:07 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
/**
|
|
|
|
* virAlloc:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes to allocate
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
* Allocate 'size' bytes of memory. Return the address of the
|
|
|
|
* allocated memory in 'ptrptr'. The newly allocated memory is
|
2013-06-07 08:37:25 +00:00
|
|
|
* filled with zeros. If @report is true, OOM errors are
|
|
|
|
* reported automatically.
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure to allocate, zero on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virAlloc(void *ptrptr,
|
|
|
|
size_t size,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2008-04-28 21:44:54 +00:00
|
|
|
{
|
2008-05-29 15:13:07 +00:00
|
|
|
#if TEST_OOM
|
|
|
|
if (virAllocTestFail()) {
|
|
|
|
*(void **)ptrptr = NULL;
|
2013-09-23 13:19:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
|
|
|
errno = ENOMEM;
|
2008-05-29 15:13:07 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
*(void **)ptrptr = calloc(1, size);
|
2013-06-07 08:37:25 +00:00
|
|
|
if (*(void **)ptrptr == NULL) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2008-04-28 21:44:54 +00:00
|
|
|
return -1;
|
2013-06-07 08:37:25 +00:00
|
|
|
}
|
2008-04-28 21:44:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virAllocN:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes to allocate
|
|
|
|
* @count: number of elements to allocate
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
2008-04-29 13:37:20 +00:00
|
|
|
* Allocate an array of memory 'count' elements long,
|
2008-04-28 21:44:54 +00:00
|
|
|
* each with 'size' bytes. Return the address of the
|
|
|
|
* allocated memory in 'ptrptr'. The newly allocated
|
2013-06-07 08:37:25 +00:00
|
|
|
* memory is filled with zeros. If @report is true,
|
|
|
|
* OOM errors are reported automatically.
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure to allocate, zero on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virAllocN(void *ptrptr,
|
|
|
|
size_t size,
|
|
|
|
size_t count,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2008-04-28 21:44:54 +00:00
|
|
|
{
|
2008-05-29 15:13:07 +00:00
|
|
|
#if TEST_OOM
|
|
|
|
if (virAllocTestFail()) {
|
|
|
|
*(void **)ptrptr = NULL;
|
2013-09-23 13:19:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
|
|
|
errno = ENOMEM;
|
2008-05-29 15:13:07 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
*(void**)ptrptr = calloc(count, size);
|
2013-06-07 08:37:25 +00:00
|
|
|
if (*(void**)ptrptr == NULL) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2008-04-28 21:44:54 +00:00
|
|
|
return -1;
|
2013-06-07 08:37:25 +00:00
|
|
|
}
|
2008-04-28 21:44:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virReallocN:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes to allocate
|
|
|
|
* @count: number of elements in array
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
* Resize the block of memory in 'ptrptr' to be an array of
|
|
|
|
* 'count' elements, each 'size' bytes in length. Update 'ptrptr'
|
|
|
|
* with the address of the newly allocated memory. On failure,
|
2008-04-29 13:37:20 +00:00
|
|
|
* 'ptrptr' is not changed and still points to the original memory
|
2010-08-13 21:00:47 +00:00
|
|
|
* block. Any newly allocated memory in 'ptrptr' is uninitialized.
|
2013-06-07 08:37:25 +00:00
|
|
|
* If @report is true, OOM errors are reported automatically.
|
2008-04-28 21:44:54 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure to allocate, zero on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virReallocN(void *ptrptr,
|
|
|
|
size_t size,
|
|
|
|
size_t count,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2008-04-28 21:44:54 +00:00
|
|
|
{
|
|
|
|
void *tmp;
|
2008-05-29 15:13:07 +00:00
|
|
|
#if TEST_OOM
|
2013-09-23 13:19:25 +00:00
|
|
|
if (virAllocTestFail()) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
|
|
|
errno = ENOMEM;
|
2008-05-29 15:13:07 +00:00
|
|
|
return -1;
|
2013-09-23 13:19:25 +00:00
|
|
|
}
|
2008-05-29 15:13:07 +00:00
|
|
|
#endif
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
if (xalloc_oversized(count, size)) {
|
2013-06-07 08:37:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2008-04-28 21:44:54 +00:00
|
|
|
errno = ENOMEM;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
tmp = realloc(*(void**)ptrptr, size * count);
|
2013-06-07 08:37:25 +00:00
|
|
|
if (!tmp && (size * count)) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2008-04-28 21:44:54 +00:00
|
|
|
return -1;
|
2013-06-07 08:37:25 +00:00
|
|
|
}
|
2008-04-28 21:44:54 +00:00
|
|
|
*(void**)ptrptr = tmp;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-08-13 21:00:47 +00:00
|
|
|
/**
|
|
|
|
* virExpandN:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes per element
|
|
|
|
* @countptr: pointer to number of elements in array
|
|
|
|
* @add: number of elements to add
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2010-08-13 21:00:47 +00:00
|
|
|
*
|
|
|
|
* Resize the block of memory in 'ptrptr' to be an array of
|
|
|
|
* '*countptr' + 'add' elements, each 'size' bytes in length.
|
|
|
|
* Update 'ptrptr' and 'countptr' with the details of the newly
|
|
|
|
* allocated memory. On failure, 'ptrptr' and 'countptr' are not
|
|
|
|
* changed. Any newly allocated memory in 'ptrptr' is zero-filled.
|
2013-06-07 08:37:25 +00:00
|
|
|
* If @report is true, OOM errors are reported automatically.
|
2010-08-13 21:00:47 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure to allocate, zero on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virExpandN(void *ptrptr,
|
|
|
|
size_t size,
|
|
|
|
size_t *countptr,
|
|
|
|
size_t add,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2010-08-13 21:00:47 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (*countptr + add < *countptr) {
|
2013-06-07 08:37:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2010-08-13 21:00:47 +00:00
|
|
|
errno = ENOMEM;
|
|
|
|
return -1;
|
|
|
|
}
|
2013-06-07 08:37:25 +00:00
|
|
|
ret = virReallocN(ptrptr, size, *countptr + add, report,
|
|
|
|
domcode, filename, funcname, linenr);
|
2010-08-13 21:00:47 +00:00
|
|
|
if (ret == 0) {
|
|
|
|
memset(*(char **)ptrptr + (size * *countptr), 0, size * add);
|
|
|
|
*countptr += add;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-08-14 15:42:51 +00:00
|
|
|
/**
|
|
|
|
* virResizeN:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes per element
|
|
|
|
* @allocptr: pointer to number of elements allocated in array
|
|
|
|
* @count: number of elements currently used in array
|
|
|
|
* @add: minimum number of additional elements to support in array
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2010-08-14 15:42:51 +00:00
|
|
|
*
|
|
|
|
* If 'count' + 'add' is larger than '*allocptr', then resize the
|
|
|
|
* block of memory in 'ptrptr' to be an array of at least 'count' +
|
|
|
|
* 'add' elements, each 'size' bytes in length. Update 'ptrptr' and
|
|
|
|
* 'allocptr' with the details of the newly allocated memory. On
|
|
|
|
* failure, 'ptrptr' and 'allocptr' are not changed. Any newly
|
2013-06-07 08:37:25 +00:00
|
|
|
* allocated memory in 'ptrptr' is zero-filled. If @report is true,
|
|
|
|
* OOM errors are reported automatically.
|
|
|
|
*
|
2010-08-14 15:42:51 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure to allocate, zero on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virResizeN(void *ptrptr,
|
|
|
|
size_t size,
|
|
|
|
size_t *allocptr,
|
|
|
|
size_t count,
|
|
|
|
size_t add,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2010-08-14 15:42:51 +00:00
|
|
|
{
|
|
|
|
size_t delta;
|
|
|
|
|
|
|
|
if (count + add < count) {
|
2013-06-07 08:37:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2010-08-14 15:42:51 +00:00
|
|
|
errno = ENOMEM;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (count + add <= *allocptr)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
delta = count + add - *allocptr;
|
|
|
|
if (delta < *allocptr / 2)
|
|
|
|
delta = *allocptr / 2;
|
2013-06-07 08:37:25 +00:00
|
|
|
return virExpandN(ptrptr, size, allocptr, delta, report,
|
|
|
|
domcode, filename, funcname, linenr);
|
2010-08-14 15:42:51 +00:00
|
|
|
}
|
|
|
|
|
2010-08-13 21:00:47 +00:00
|
|
|
/**
|
|
|
|
* virShrinkN:
|
|
|
|
* @ptrptr: pointer to pointer for address of allocated memory
|
|
|
|
* @size: number of bytes per element
|
|
|
|
* @countptr: pointer to number of elements in array
|
2010-11-23 13:31:43 +00:00
|
|
|
* @toremove: number of elements to remove
|
2010-08-13 21:00:47 +00:00
|
|
|
*
|
|
|
|
* Resize the block of memory in 'ptrptr' to be an array of
|
2010-11-23 13:31:43 +00:00
|
|
|
* '*countptr' - 'toremove' elements, each 'size' bytes in length.
|
2010-08-13 21:00:47 +00:00
|
|
|
* Update 'ptrptr' and 'countptr' with the details of the newly
|
2010-11-23 13:31:43 +00:00
|
|
|
* allocated memory. If 'toremove' is larger than 'countptr', free
|
2010-08-13 21:00:47 +00:00
|
|
|
* the entire array.
|
|
|
|
*/
|
2010-11-23 13:31:43 +00:00
|
|
|
void virShrinkN(void *ptrptr, size_t size, size_t *countptr, size_t toremove)
|
2010-08-13 21:00:47 +00:00
|
|
|
{
|
2014-09-03 19:39:21 +00:00
|
|
|
if (toremove < *countptr) {
|
2013-06-07 08:37:25 +00:00
|
|
|
ignore_value(virReallocN(ptrptr, size, *countptr -= toremove,
|
|
|
|
false, 0, NULL, NULL, 0));
|
2014-09-03 19:39:21 +00:00
|
|
|
} else {
|
2010-08-13 21:00:47 +00:00
|
|
|
virFree(ptrptr);
|
|
|
|
*countptr = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
/**
|
|
|
|
* virInsertElementsN:
|
|
|
|
* @ptrptr: pointer to hold address of allocated memory
|
|
|
|
* @size: the size of one element in bytes
|
alloc: make VIR_APPEND_ELEMENT safer
VIR_APPEND_ELEMENT(array, size, elem) was not safe if the expression
for 'size' had side effects. While no one in the current code base
was trying to pass side effects, we might as well be robust and
explicitly document our intentions.
* src/util/viralloc.c (virInsertElementsN): Add special case.
* src/util/viralloc.h (VIR_APPEND_ELEMENT): Use it.
(VIR_ALLOC, VIR_ALLOC_N, VIR_REALLOC_N, VIR_EXPAND_N)
(VIR_RESIZE_N, VIR_SHRINK_N, VIR_INSERT_ELEMENT)
(VIR_DELETE_ELEMENT, VIR_ALLOC_VAR, VIR_FREE): Document
which macros are safe in the presence of side effects.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-05-06 22:21:15 +00:00
|
|
|
* @at: index within array where new elements should be added, -1 for end
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
* @countptr: variable tracking number of elements currently allocated
|
|
|
|
* @add: number of elements to add
|
|
|
|
* @newelems: pointer to array of one or more new elements to move into
|
|
|
|
* place (the originals will be zeroed out if successful
|
|
|
|
* and if clearOriginal is true)
|
|
|
|
* @clearOriginal: false if the new item in the array should be copied
|
|
|
|
* from the original, and the original left intact.
|
|
|
|
* true if the original should be 0'd out on success.
|
|
|
|
* @inPlace: false if we should expand the allocated memory before
|
|
|
|
* moving, true if we should assume someone else *has
|
|
|
|
* already* done that.
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
*
|
|
|
|
* Re-allocate an array of *countptr elements, each sizeof(*ptrptr) bytes
|
|
|
|
* long, to be *countptr+add elements long, then appropriately move
|
|
|
|
* the elements starting at ptrptr[at] up by add elements, copy the
|
|
|
|
* items from newelems into ptrptr[at], then store the address of
|
|
|
|
* allocated memory in *ptrptr and the new size in *countptr. If
|
|
|
|
* newelems is NULL, the new elements at ptrptr[at] are instead filled
|
alloc: make VIR_APPEND_ELEMENT safer
VIR_APPEND_ELEMENT(array, size, elem) was not safe if the expression
for 'size' had side effects. While no one in the current code base
was trying to pass side effects, we might as well be robust and
explicitly document our intentions.
* src/util/viralloc.c (virInsertElementsN): Add special case.
* src/util/viralloc.h (VIR_APPEND_ELEMENT): Use it.
(VIR_ALLOC, VIR_ALLOC_N, VIR_REALLOC_N, VIR_EXPAND_N)
(VIR_RESIZE_N, VIR_SHRINK_N, VIR_INSERT_ELEMENT)
(VIR_DELETE_ELEMENT, VIR_ALLOC_VAR, VIR_FREE): Document
which macros are safe in the presence of side effects.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-05-06 22:21:15 +00:00
|
|
|
* with zero. at must be between [0,*countptr], except that -1 is
|
2013-06-07 08:37:25 +00:00
|
|
|
* treated the same as *countptr for convenience. If @report is true,
|
|
|
|
* OOM errors are reported automatically.
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure, 0 on success
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
virInsertElementsN(void *ptrptr, size_t size, size_t at,
|
|
|
|
size_t *countptr,
|
|
|
|
size_t add, void *newelems,
|
2013-06-07 08:37:25 +00:00
|
|
|
bool clearOriginal, bool inPlace,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
{
|
alloc: make VIR_APPEND_ELEMENT safer
VIR_APPEND_ELEMENT(array, size, elem) was not safe if the expression
for 'size' had side effects. While no one in the current code base
was trying to pass side effects, we might as well be robust and
explicitly document our intentions.
* src/util/viralloc.c (virInsertElementsN): Add special case.
* src/util/viralloc.h (VIR_APPEND_ELEMENT): Use it.
(VIR_ALLOC, VIR_ALLOC_N, VIR_REALLOC_N, VIR_EXPAND_N)
(VIR_RESIZE_N, VIR_SHRINK_N, VIR_INSERT_ELEMENT)
(VIR_DELETE_ELEMENT, VIR_ALLOC_VAR, VIR_FREE): Document
which macros are safe in the presence of side effects.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-05-06 22:21:15 +00:00
|
|
|
if (at == -1) {
|
|
|
|
at = *countptr;
|
|
|
|
} else if (at > *countptr) {
|
2013-06-07 08:37:25 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("out of bounds index - count %zu at %zu add %zu"),
|
|
|
|
*countptr, at, add);
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (inPlace) {
|
|
|
|
*countptr += add;
|
2013-06-07 08:37:25 +00:00
|
|
|
} else if (virExpandN(ptrptr, size, countptr, add, report,
|
|
|
|
domcode, filename, funcname, linenr) < 0) {
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* memory was successfully re-allocated. Move up all elements from
|
|
|
|
* ptrptr[at] to the end (if we're not "inserting" at the end
|
|
|
|
* already), memcpy in the new elements, and clear the elements
|
|
|
|
* from their original location. Remember that *countptr has
|
|
|
|
* already been updated with new element count!
|
|
|
|
*/
|
|
|
|
if (at < *countptr - add) {
|
|
|
|
memmove(*(char**)ptrptr + (size * (at + add)),
|
|
|
|
*(char**)ptrptr + (size * at),
|
|
|
|
size * (*countptr - add - at));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (newelems) {
|
|
|
|
memcpy(*(char**)ptrptr + (size * at), newelems, size * add);
|
|
|
|
if (clearOriginal)
|
|
|
|
memset((char*)newelems, 0, size * add);
|
|
|
|
} else if (inPlace || (at < *countptr - add)) {
|
|
|
|
/* NB: if inPlace, assume memory at the end wasn't initialized */
|
|
|
|
memset(*(char**)ptrptr + (size * at), 0, size * add);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virDeleteElementsN:
|
|
|
|
* @ptrptr: pointer to hold address of allocated memory
|
|
|
|
* @size: the size of one element in bytes
|
|
|
|
* @at: index within array where new elements should be deleted
|
|
|
|
* @countptr: variable tracking number of elements currently allocated
|
2013-03-07 14:53:42 +00:00
|
|
|
* @toremove: number of elements to remove
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
* @inPlace: false if we should shrink the allocated memory when done,
|
|
|
|
* true if we should assume someone else will do that.
|
|
|
|
*
|
|
|
|
* Re-allocate an array of *countptr elements, each sizeof(*ptrptr)
|
|
|
|
* bytes long, to be *countptr-remove elements long, then store the
|
|
|
|
* address of allocated memory in *ptrptr and the new size in *countptr.
|
|
|
|
* If *countptr <= remove, the entire array is freed.
|
|
|
|
*
|
|
|
|
* Returns -1 on failure, 0 on success
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
virDeleteElementsN(void *ptrptr, size_t size, size_t at,
|
2013-03-07 14:53:42 +00:00
|
|
|
size_t *countptr, size_t toremove,
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
bool inPlace)
|
|
|
|
{
|
2013-03-07 14:53:42 +00:00
|
|
|
if (at + toremove > *countptr) {
|
|
|
|
VIR_WARN("out of bounds index - count %zu at %zu toremove %zu",
|
|
|
|
*countptr, at, toremove);
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* First move down the elements at the end that won't be deleted,
|
|
|
|
* then realloc. We assume that the items being deleted have
|
|
|
|
* already been cleared.
|
|
|
|
*/
|
|
|
|
memmove(*(char**)ptrptr + (size * at),
|
2013-03-07 14:53:42 +00:00
|
|
|
*(char**)ptrptr + (size * (at + toremove)),
|
|
|
|
size * (*countptr - toremove - at));
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
if (inPlace)
|
2013-03-07 14:53:42 +00:00
|
|
|
*countptr -= toremove;
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
else
|
2013-03-07 14:53:42 +00:00
|
|
|
virShrinkN(ptrptr, size, countptr, toremove);
|
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT
I noticed when writing the backend functions for virNetworkUpdate that
I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and
messed up the args to memmove at least once), and had seen the same
sequence in a lot of other places, so I decided to write a few
utility functions/macros - see the .h file for full documentation.
The intent is to reduce the number of lines of code, but more
importantly to eliminate the need to check the element size and
element count arithmetic every time we need to do this (I *always*
make at least one mistake.)
VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an
array of objects. The size of each object is determined
automatically by the macro using sizeof(*array). The new element's
contents are copied into the inserted space, then the original copy
of contents are 0'ed out (if everything else was
successful). Compile-time assignment and size compatibility between
the array and the new element is guaranteed (see explanation below
[*])
VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT
that "inserts" one past the current last element.
VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that
the original contents of newelem are not cleared to 0 (i.e. a copy
is made).
VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an
array of objects. It's assumed that the element being deleted is
already saved elsewhere (or cleared, if that's what is appropriate).
All five of these macros have an _INPLACE variant, which skips the
memory re-allocation of the array, assuming that the caller has
already done it (when inserting) or will do it later (when deleting).
Note that VIR_DELETE_ELEMENT* can return a failure, but only if an
invalid index is given (index + amount to delete is > current array
size), so in most cases you can safely ignore the return (that's why
the helper function virDeleteElementsN isn't declared with
ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens,
since it is surely a coding error.
[*] One initial problem with the INSERT and APPEND macros was that,
due to both the array pointer and newelem pointer being cast to void*
when passing to virInsertElementsN(), any chance of type-checking was
lost. If we were going to move in newelem with a memmove anyway, we
would be no worse off for this. However, most current open-coded
insert/append operations use direct struct assignment to move the new
element into place (or just populate the new element directly) - thus
use of the new macros would open a possibility for new usage errors
that didn't exist before (e.g. accidentally sending &newelemptr rather
than newelemptr - I actually did this quite a lot in my test
conversions of existing code).
But thanks to Eric Blake's clever thinking, I was able to modify the
INSERT and APPEND macros so that they *do* check for both assignment
and size compatibility of *ptr (an element in the array) and newelem
(the element being copied into the new position of the array). This is
done via clever use of the C89-guaranteed fact that the sizeof()
operator must have *no* side effects (so an assignment inside sizeof()
is checked for validity, but not actually evaluated), and the fact
that virInsertElementsN has a "# of new elements" argument that we
want to always be 1.
2012-10-08 17:33:35 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2010-08-13 21:00:47 +00:00
|
|
|
|
2010-04-05 17:11:34 +00:00
|
|
|
/**
|
2013-03-22 11:59:31 +00:00
|
|
|
* virAllocVar:
|
2010-04-05 17:11:34 +00:00
|
|
|
* @ptrptr: pointer to hold address of allocated memory
|
|
|
|
* @struct_size: size of initial struct
|
|
|
|
* @element_size: size of array elements
|
|
|
|
* @count: number of array elements to allocate
|
2013-06-07 08:37:25 +00:00
|
|
|
* @report: whether to report OOM error, if there is one
|
|
|
|
* @domcode: error domain code
|
|
|
|
* @filename: caller's filename
|
|
|
|
* @funcname: caller's funcname
|
|
|
|
* @linenr: caller's line number
|
2010-04-05 17:11:34 +00:00
|
|
|
*
|
|
|
|
* Allocate struct_size bytes plus an array of 'count' elements, each
|
|
|
|
* of size element_size. This sort of allocation is useful for
|
|
|
|
* receiving the data of certain ioctls and other APIs which return a
|
|
|
|
* struct in which the last element is an array of undefined length.
|
|
|
|
* The caller of this type of API is expected to know the length of
|
|
|
|
* the array that will be returned and allocate a suitable buffer to
|
|
|
|
* contain the returned data. C99 refers to these variable length
|
2013-06-07 08:37:25 +00:00
|
|
|
* objects as structs containing flexible array members. If @report
|
|
|
|
* is true, OOM errors are reported automatically.
|
2010-04-05 17:11:34 +00:00
|
|
|
*
|
|
|
|
* Returns -1 on failure, 0 on success
|
|
|
|
*/
|
2013-06-07 08:37:25 +00:00
|
|
|
int virAllocVar(void *ptrptr,
|
|
|
|
size_t struct_size,
|
|
|
|
size_t element_size,
|
|
|
|
size_t count,
|
|
|
|
bool report,
|
|
|
|
int domcode,
|
|
|
|
const char *filename,
|
|
|
|
const char *funcname,
|
|
|
|
size_t linenr)
|
2010-04-05 17:11:34 +00:00
|
|
|
{
|
|
|
|
size_t alloc_size = 0;
|
|
|
|
|
|
|
|
#if TEST_OOM
|
2013-09-23 13:19:25 +00:00
|
|
|
if (virAllocTestFail()) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
|
|
|
errno = ENOMEM;
|
2010-04-05 17:11:34 +00:00
|
|
|
return -1;
|
2013-09-23 13:19:25 +00:00
|
|
|
}
|
2010-04-05 17:11:34 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
if (VIR_ALLOC_VAR_OVERSIZED(struct_size, count, element_size)) {
|
2013-06-07 08:37:25 +00:00
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2010-04-05 17:11:34 +00:00
|
|
|
errno = ENOMEM;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
alloc_size = struct_size + (element_size * count);
|
|
|
|
*(void **)ptrptr = calloc(1, alloc_size);
|
2013-06-07 08:37:25 +00:00
|
|
|
if (*(void **)ptrptr == NULL) {
|
|
|
|
if (report)
|
|
|
|
virReportOOMErrorFull(domcode, filename, funcname, linenr);
|
2010-04-05 17:11:34 +00:00
|
|
|
return -1;
|
2013-06-07 08:37:25 +00:00
|
|
|
}
|
2010-04-05 17:11:34 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
/**
|
|
|
|
* virFree:
|
|
|
|
* @ptrptr: pointer to pointer for address of memory to be freed
|
|
|
|
*
|
|
|
|
* Release the chunk of memory in the pointer pointed to by
|
|
|
|
* the 'ptrptr' variable. After release, 'ptrptr' will be
|
|
|
|
* updated to point to NULL.
|
|
|
|
*/
|
2008-11-17 11:03:25 +00:00
|
|
|
void virFree(void *ptrptr)
|
2008-04-28 21:44:54 +00:00
|
|
|
{
|
2010-12-23 18:23:42 +00:00
|
|
|
int save_errno = errno;
|
|
|
|
|
2008-04-28 21:44:54 +00:00
|
|
|
free(*(void**)ptrptr);
|
|
|
|
*(void**)ptrptr = NULL;
|
2010-12-23 18:23:42 +00:00
|
|
|
errno = save_errno;
|
2008-04-28 21:44:54 +00:00
|
|
|
}
|
2016-05-13 12:59:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virDispose:
|
|
|
|
* @ptrptr: pointer to pointer for address of memory to be sanitized and freed
|
|
|
|
* @count: count of elements in the array to dispose
|
|
|
|
* @elemet_size: size of one element
|
|
|
|
* @countptr: pointer to the count variable to clear (may be NULL)
|
|
|
|
*
|
|
|
|
* Clear and release the chunk of memory in the pointer pointed to by 'prtptr'.
|
|
|
|
*
|
|
|
|
* If @countptr is provided, it's value is used instead of @count and it's set
|
|
|
|
* to 0 after clearing and freeing the memory.
|
|
|
|
*
|
|
|
|
* After release, 'ptrptr' will be updated to point to NULL.
|
|
|
|
*/
|
|
|
|
void virDispose(void *ptrptr,
|
|
|
|
size_t count,
|
|
|
|
size_t element_size,
|
|
|
|
size_t *countptr)
|
|
|
|
{
|
|
|
|
int save_errno = errno;
|
|
|
|
|
|
|
|
if (countptr)
|
|
|
|
count = *countptr;
|
|
|
|
|
|
|
|
if (*(void**)ptrptr && count > 0)
|
|
|
|
memset(*(void **)ptrptr, 0, count * element_size);
|
|
|
|
|
|
|
|
free(*(void**)ptrptr);
|
|
|
|
*(void**)ptrptr = NULL;
|
|
|
|
|
|
|
|
if (countptr)
|
|
|
|
*countptr = 0;
|
|
|
|
errno = save_errno;
|
|
|
|
}
|