Re: bglibs-1.022/str/alloc.c comment

Hi,

Thanks for your answer.

Bruce Guenter wrote:
> 
> This comparison is done to protect against additive overflow.  That is,
> trying to allocate a string whose size would overflow an unsigned
> integer will fail instead of producing bugs.
> 

Ok, I see.

> 
>>Anyway with the above construct it doesn't seem possible to resize a string 
>>to something less than the actual size. It that correct ?
> 
> The str library is set up to always grow, never shrink, yes.  The only
> way to shrink would be to free the string (which resets the size
> parameter) and then reallocate it.

Is there any special reason why you don't use realloc() in str_alloc() - and use malloc/memcpy/free instead ?

Kind regards Uffe Jakobsen