[Cmake] Buffer overflows
perera at cs . rpi . edu
Fri, 22 Jun 2001 11:57:46 -0400
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
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.
On Fri, Jun 22, 2001 at 09:14:56AM -0400, Bill Hoffman wrote:
> 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
> >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) );
> >Cmake mailing list
> >Cmake at public . kitware . com
> >http://public . kitware . com/mailman/listinfo/cmake