Bug in gr_scrambler?

GNU Radio
1

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

2

Following up to my last- it seems I’ve generally misunderstood the valve
block. (also, my code example was off the top of my head and incorrect).

Please disregard the other post on this thread. Thanks.

-Brett

3

On Wed, Dec 08, 2010 at 12:55:20PM -0600, Brett L. Trotter wrote:

unsigned char *out = (unsigned char *) output_items[0];
this potentially reading past the end of the input items?
This is correct; gr_scrambler_bb is a gr_sync_block, which in turn
guarantees that noutput_items == ninput_items.

I’m pretty sure the bug isn’t in gr_scrambler_bb. I bet if you connect a
vector_ or file_sink to both the input and output streams of
gr_scrambler_bb, they will have the same size.

Cheers,
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

4

On Wed, Dec 8, 2010 at 1:55 PM, Brett L. Trotter [email protected]
wrote:

const unsigned char *in = (const unsigned char *) input_items[0];
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