This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minor off-by-one error in command_line_handler


> The other problem is with the ALL_BLOCK_SYMBOLS macro.  It looks
> like this
> 
> /* Macro to loop through all symbols in a block BL.
>    i counts which symbol we are looking at, and sym points to the current
>    symbol.  */
> #define ALL_BLOCK_SYMBOLS(bl, i, sym)                   \
>         for ((i) = 0, (sym) = BLOCK_SYM ((bl), (i));    \
>              (i) < BLOCK_NSYMS ((bl));                  \
>              ++(i), (sym) = BLOCK_SYM ((bl), (i)))
> 
> Where the block structure (BL) ends with an array of pointers to
> symbols.  The third expression in the for statement increments the
> index variable and reads the address at the i'th element of the
> bl->sym[] array.
> 
> So when a block has 2 symbols, bl->sym[0] and bl->sym[1] contain
> values.  On the last evaluation of this loop, i is pre-incremented
> from 1 to 2 and the statement 'sym = bl->nsym[2]' is done - we're
> reading one element past the end of the array.
> 
> The invalid memory we just read is not used -- the conditional
> expression is then evaluated and the loop exits.  The only way
> I can see this causing a problem is on a system where reading
> that unallocated word of memory would cause a segfault.  Unless
> other people have heard complaints about gdb 5.1 doing so, I
> don't think this is worth worrying about. 

Yes I'd agree. Perhaphs create a very non-critical bug report for this one.

Andrew




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]