discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Bug in gr_scrambler?


From: Brett L. Trotter
Subject: [Discuss-gnuradio] Re: Bug in gr_scrambler?
Date: Wed, 08 Dec 2010 22:12:01 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100410 CentOS/3.0.4-2 Lightning/1.0b1 Thunderbird/3.0.4

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

On 12/08/2010 12:55 PM, Brett L. Trotter 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?
>
> 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
>   




reply via email to

[Prev in Thread] Current Thread [Next in Thread]