lalitmetkar / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

Array index is used before limits check in ops.c #70

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
cppcheck static analyzer gives this warning in src/ops.c (Vim-7.3.566):

[ops.c:6461]: (style) Array index i is used before limits check

Code is src/ops.c:6461:

6434 /*
6435  *  Count the number of bytes, characters and "words" in a line.
6436  *
6437  *  "Words" are counted by looking for boundaries between non-space and
6438  *  space characters.  (it seems to produce results that match 'wc'.)
6439  *
6440  *  Return value is byte count; word count for the line is added to "*wc".
6441  *  Char count is added to "*cc".
6442  *
6443  *  The function will only examine the first "limit" characters in the
6444  *  line, stopping if it encounters an end-of-line (NUL byte).  In that
6445  *  case, eol_size will be added to the character count to account for
6446  *  the size of the EOL character.
6447  */
6448     static long
6449 line_count_info(line, wc, cc, limit, eol_size)
6450     char_u      *line;
6451     long        *wc;
6452     long        *cc;
6453     long        limit;
6454     int         eol_size;
6455 {
6456     long        i;
6457     long        words = 0;
6458     long        chars = 0;
6459     int         is_word = 0;
6460 
6461     for (i = 0; line[i] && i < limit; )
6462     {

Notice that comment at line ops.c:6443 says that function will
only examine the first "limit" characters in the line. Yet line
ops.c:6461 can read one more character.

It's unlikely to cause serious issues unless line[limit] happens
to be at a memory page boundary with next page unmapped
in which case it could segfault (but it's unlikely!).  It's
easy to fix by swapping the conditions at line ops.c:6461 
as in attached patch.

Original issue reported on code.google.com by dominiqu...@gmail.com on 24 Jun 2012 at 7:07

Attachments:

GoogleCodeExporter commented 9 years ago
Patch included as 7.3.573

Original comment by brammool...@gmail.com on 29 Jun 2012 at 11:27