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?
Shouldn't the above be something like:
int
gr_scrambler_bb::general_work(int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const int ninput_items = ninput_items[0];
const unsigned char *in = (const unsigned char *) input_items[0];
unsigned char *out = (unsigned char *) output_items[0];
for (int i = 0; i < ninput_items; i++)
out[i] = d_lfsr.next_bit_scramble(in[i]);
return ninput_items;
}
Regardless of whether there are sufficient input items to read, is there
a reason the scrambler block should continue outputting when the input
stream shuts off, sending zeroes or random data when you don't
necessarily want anything going out?
Is this a bug or an intended feature?
-Brett
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
