Re: [Discuss-gnuradio] Bug in gr_scrambler?

[Tom Rondeau]

On Wed, Dec 8, 2010 at 1:55 PM, Brett L. Trotter <address@hidden> wrote:
> I observed today with a controlled test using valve blocks that the
> scrambler block continues to output data even when no input data should
> be coming in. I then looked at the source:
>
>
> int
> gr_scrambler_bb::work(int noutput_items,
>                      gr_vector_const_void_star &input_items,
>                      gr_vector_void_star &output_items)
> {
>  const unsigned char *in = (const unsigned char *) input_items[0];
>  unsigned char *out = (unsigned char *) output_items[0];
>
>  for (int i = 0; i < noutput_items; i++)
>    out[i] = d_lfsr.next_bit_scramble(in[i]);
>
>  return noutput_items;
> }
>
> It seems to be looking only at the number of requested output items and
> outputting anyway. Unless the input_items[0] array is guaranteed to be
> filled with zeroes to the length of the number of output items, isn't
> this potentially reading past the end of the input items?

Brett,
I know you said to disregard this in a later email, but I thought I'd
use it to clear something up for people who might be confused.

The gr_scrambler_bb block inherits from gr_sync_block, which means
that the number of output items equals the number of input items (a
1-to-1 relationship). So the scheduler tells a gr_sync_block that if
there are N items it's able to produce, the block knows it has N items
on the input(s) to consume. So you are guaranteed to have
noutput_items available on the input buffer for these blocks.

Tom