2018-11-27 19:20:32 +00:00
|
|
|
/*
|
|
|
|
* PuTTY's memory allocation wrappers.
|
|
|
|
*/
|
|
|
|
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
#include <assert.h>
|
2018-11-27 19:20:32 +00:00
|
|
|
#include <stdlib.h>
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 08:44:11 +00:00
|
|
|
#include <limits.h>
|
2018-11-27 19:20:32 +00:00
|
|
|
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 08:44:11 +00:00
|
|
|
#include "defs.h"
|
|
|
|
#include "puttymem.h"
|
2019-03-01 19:25:47 +00:00
|
|
|
#include "misc.h"
|
2018-11-27 19:20:32 +00:00
|
|
|
|
|
|
|
void *safemalloc(size_t n, size_t size)
|
|
|
|
{
|
|
|
|
void *p;
|
|
|
|
|
|
|
|
if (n > INT_MAX / size) {
|
|
|
|
p = NULL;
|
|
|
|
} else {
|
|
|
|
size *= n;
|
|
|
|
if (size == 0) size = 1;
|
|
|
|
#ifdef MINEFIELD
|
|
|
|
p = minefield_c_malloc(size);
|
|
|
|
#else
|
|
|
|
p = malloc(size);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 08:44:11 +00:00
|
|
|
if (!p)
|
|
|
|
out_of_memory();
|
|
|
|
|
2018-11-27 19:20:32 +00:00
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
void *saferealloc(void *ptr, size_t n, size_t size)
|
|
|
|
{
|
|
|
|
void *p;
|
|
|
|
|
|
|
|
if (n > INT_MAX / size) {
|
|
|
|
p = NULL;
|
|
|
|
} else {
|
|
|
|
size *= n;
|
|
|
|
if (!ptr) {
|
|
|
|
#ifdef MINEFIELD
|
|
|
|
p = minefield_c_malloc(size);
|
|
|
|
#else
|
|
|
|
p = malloc(size);
|
|
|
|
#endif
|
|
|
|
} else {
|
|
|
|
#ifdef MINEFIELD
|
|
|
|
p = minefield_c_realloc(ptr, size);
|
|
|
|
#else
|
|
|
|
p = realloc(ptr, size);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 08:44:11 +00:00
|
|
|
if (!p)
|
|
|
|
out_of_memory();
|
|
|
|
|
2018-11-27 19:20:32 +00:00
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
void safefree(void *ptr)
|
|
|
|
{
|
|
|
|
if (ptr) {
|
|
|
|
#ifdef MINEFIELD
|
|
|
|
minefield_c_free(ptr);
|
|
|
|
#else
|
|
|
|
free(ptr);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
}
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
|
|
|
|
void *safegrowarray(void *ptr, size_t *allocated, size_t eltsize,
|
2019-03-01 19:25:47 +00:00
|
|
|
size_t oldlen, size_t extralen, bool secret)
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
{
|
|
|
|
/* The largest value we can safely multiply by eltsize */
|
|
|
|
assert(eltsize > 0);
|
|
|
|
size_t maxsize = (~(size_t)0) / eltsize;
|
|
|
|
|
|
|
|
size_t oldsize = *allocated;
|
|
|
|
|
|
|
|
/* Range-check the input values */
|
|
|
|
assert(oldsize <= maxsize);
|
|
|
|
assert(oldlen <= maxsize);
|
|
|
|
assert(extralen <= maxsize - oldlen);
|
|
|
|
|
|
|
|
/* If the size is already enough, don't bother doing anything! */
|
|
|
|
if (oldsize > oldlen + extralen)
|
|
|
|
return ptr;
|
|
|
|
|
|
|
|
/* Find out how much we need to grow the array by. */
|
|
|
|
size_t increment = (oldlen + extralen) - oldsize;
|
|
|
|
|
|
|
|
/* Invent a new size. We want to grow the array by at least
|
|
|
|
* 'increment' elements; by at least a fixed number of bytes (to
|
|
|
|
* get things started when sizes are small); and by some constant
|
|
|
|
* factor of its old size (to avoid repeated calls to this
|
|
|
|
* function taking quadratic time overall). */
|
|
|
|
if (increment < 256 / eltsize)
|
|
|
|
increment = 256 / eltsize;
|
|
|
|
if (increment < oldsize / 16)
|
|
|
|
increment = oldsize / 16;
|
|
|
|
|
|
|
|
/* But we also can't grow beyond maxsize. */
|
|
|
|
size_t maxincr = maxsize - oldsize;
|
|
|
|
if (increment > maxincr)
|
|
|
|
increment = maxincr;
|
|
|
|
|
|
|
|
size_t newsize = oldsize + increment;
|
2019-03-01 19:25:47 +00:00
|
|
|
void *toret;
|
|
|
|
if (secret) {
|
|
|
|
toret = safemalloc(newsize, eltsize);
|
|
|
|
memcpy(toret, ptr, oldsize * eltsize);
|
|
|
|
smemclr(ptr, oldsize * eltsize);
|
|
|
|
sfree(ptr);
|
|
|
|
} else {
|
|
|
|
toret = saferealloc(ptr, newsize, eltsize);
|
|
|
|
}
|
New array-growing macros: sgrowarray and sgrowarrayn.
The idea of these is that they centralise the common idiom along the
lines of
if (logical_array_len >= physical_array_size) {
physical_array_size = logical_array_len * 5 / 4 + 256;
array = sresize(array, physical_array_size, ElementType);
}
which happens at a zillion call sites throughout this code base, with
different random choices of the geometric factor and additive
constant, sometimes forgetting them completely, and generally doing a
lot of repeated work.
The new macro sgrowarray(array,size,n) has the semantics: here are the
array pointer and its physical size for you to modify, now please
ensure that the nth element exists, so I can write into it. And
sgrowarrayn(array,size,n,m) is the same except that it ensures that
the array has size at least n+m (so sgrowarray is just the special
case where m=1).
Now that this is a single centralised implementation that will be used
everywhere, I've also gone to more effort in the implementation, with
careful overflow checks that would have been painful to put at all the
previous call sites.
This commit also switches over every use of sresize(), apart from a
few where I really didn't think it would gain anything. A consequence
of that is that a lot of array-size variables have to have their types
changed to size_t, because the macros require that (they address-take
the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
|
|
|
*allocated = newsize;
|
|
|
|
return toret;
|
|
|
|
}
|