Lines Matching refs:allocated

60 or dynamically allocated memory (@pxref{Memory Allocation}).  It's up to
109 The amount of memory allocated for a byte array may extend past the null byte
111 document, the term @dfn{allocated size} is always used to refer to the
112 total amount of memory allocated for an array, while the term
123 string than fit in its allocated size.  When writing code that extends
124 strings or moves bytes into a pre-allocated array, you should be
244 the length of the string stored there, not its allocated size.  You can
245 get the allocated size of the array that holds a string using
371 function might get stuck in a loop trashing all the memory allocated to
568 allocated string.  The string is allocated using @code{malloc}; see
578 into a newly allocated string.  The string is allocated using
629 limitations as any block of memory allocated using @code{alloca}.
731 since how can one otherwise ensure the allocated size of the buffer is
787   size_t allocated = 100;
788   char *result = malloc (allocated);
802           /* @r{Resize the allocated memory if necessary.}  */
803           if (resultlen + len + 1 > allocated)
805               allocated += len;
806               newp = reallocarray (result, allocated, 2);
807               allocated *= 2;
913 @var{size} bytes into the newly allocated string.
1011 allocated size of @var{to} must be at least @code{@var{size} + 1} bytes
1044 character is also always appended to @var{to}, so the total allocated
1167 than their allocated size.  The contents of these ``holes'' are
1531 what size the allocated array should be.  It does not matter what
1561 useful for determining what size the allocated array should be (remember
1640   /* @r{Free the strings we allocated.} */
2653 grow a string expects that string to have been allocated using
2697 @var{Argv} must be pre-allocated with enough space to hold all the