From: Michael Neumann <mneumann@...>
Date: 2003-06-14T05:00:01+09:00
Subject: Re: Hispeed String concat / Failsafe (RE)ALLOC_N usage?

On Sat, Jun 14, 2003 at 03:46:08AM +0900, Josef 'Jupp' Schugt wrote:
> Saluton!
> 
> This message contains a C implementation of a string buffer (see
> below). It is an alpha version because I have no information about
> the behavior of ALLOC_N and REALLOC_N in the case of a memory
> allocation failure -  I didn't find any documentation on that topic.
> Besides that it seems to be bullet-proof (I use it to to concatenate
> chunks of all mails I download from my POP3 accounts - which is the
> reason why I want to avoid vulnerabilities).
> 
> As every C programmer knows not checking the return value of 'malloc'
> is a vulnerability to be exploited. In the case of the Rubyish
> routines ALLOC_N and REALLOC_N two different behaviors are equally
> likely:
> 
>  - return NULL buffer in the same way as plain C functions do
> 
>  - raise an exception

It raises a NoMemoryException (see ruby_xmalloc in gc.c). So you don't
need to test weather if returns NULL or not. 

> I did assume the latter but if the former is true that will mean the
> code given below is vulnerable to exploits!
> 
> * Dominik Werder; 2003-06-13, 13:18 UTC:
> > What is the fastest way to add many small Strings to a big buffer?
> 
> Follows my C version for that problem: 'new' set size of buffer,
> append does append to it (if capacity is too slow it is automagically
> increased), get gets whole buffer.

Why not make Storage a class, so you can have more than one? Your
current implementation does not allow this.  You'd need to use
Data_Make_Struct and Data_Get_Struct.

This way, you wouldn't need the global variables.


Regards,

  Michael

-- 
ruby -r complex -e 'c,m,w,h=Complex(-0.75,0.136),50,150,100;puts "P6\n#{w} #{h}\n255";(0...h).each{|j|(0...w).each{|i|
n,z=0,Complex(.9*i/w,.9*j/h);while n<=m&&(z-c).abs<=2;z=z*z+c;n+=1 end;print [10+n*15,0,rand*99].pack("C*")}}'|display