[Cmake] Buffer overflows

[Amitha Perera]

I agree there isn't a real buffer overflow. At 4am, fixed sized buffer
= generic buffer overflow. :-)

The problem is that getline, if it does not see the delimiter,
extracts n-1 characters _and_ calls setstate(failbit). This makes
(!fin) true, and the loops terminates as soon as a very long line is
seen.

I'm not sure that reading character-by-character, especially using the
stream iterators, is any less efficient. There isn't (shouldn't be) a
disk access per iterator dereference, since these are buffered
streams, and copying from one stream's buffer directly to the other
stream's buffer seems more efficient that reading into a temporary
buffer first. However, this does imply doing things like
fin.setf(ios::skipws), or, according to the standard,
fin.setf(ios_base::skipws). Maybe it's best to avoid such issues.

Anyway, I guess the simplest solution is just to check for fin.fail()
after the readline, and reset the flag if it does happen.

Amitha.



On Fri, Jun 22, 2001 at 09:14:56AM -0400, Bill Hoffman wrote:
> 
> 
> basic_istream::getline
> basic_istream& getline(E *s, streamsize n);
> basic_istream& getline(E *s, streamsize n, E delim);
> The first of these unformatted input functions returns getline(s, n, widen('\n')).
> The second function extracts up to n - 1 elements and stores them in the array beginning at s. It always stores E(0) after any extracted elements it stores. In order of testing, extraction stops:  
> At end of file. 
> After the function extracts an element that compares equal to delim, in which case the element is neither put back nor appended to the controlled sequence. 
> After the function extracts is.max_size() elements. 
> If the function extracts no elements, it calls setstate(failbit). In any case, it returns *this.
> 
> There is no buffer overflow here:  "extracts up to n - 1 elements"
> However, the loop is slightly wrong, in some cases it could duplicate
> the last line of the file.  We will fix that problem.
> The getline code should be much more efficient than reading a character at 
> a time.
> 
> 
> At 03:58 AM 6/22/2001 -0400, you wrote:
> >Could we please, please avoid using fixed-sized buffers, no matter
> >how big the buffer is? I just spent the last 3 hrs tracking down
> > char  buff[4096]
> >in cmSystemTools::cmCopyFile.
> >
> >Is there any reason why this function couldn't be implemented using
> >iterators? For example:
> >
> >void cmSystemTools::cmCopyFile(const char* source,
> >                             const char* destination)
> >{
> >  std::ifstream fin(source);
> >  std::ofstream fout(destination);
> >  std::copy( std::istream_iterator<char>(fin), std::istream_iterator<char>(), std::ostream_iterator<char>(fout) );
> >}
> >
> >Amitha.
> >
> >_______________________________________________
> >Cmake mailing list
> >Cmake at public.kitware.com
> >http://public.kitware.com/mailman/listinfo/cmake