[Top][All Lists]

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

Re: [Discuss-gnuradio] Bug in gr_scrambler?

From: Martin Braun
Subject: Re: [Discuss-gnuradio] Bug in gr_scrambler?
Date: Thu, 9 Dec 2010 18:00:14 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Dec 08, 2010 at 12:55:20PM -0600, 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?

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.


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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstra├če 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071

KIT -- University of the State of Baden-W├╝rttemberg and
National Laboratory of the Helmholtz Association

Attachment: pgpQ0QKKHWQrp.pgp
Description: PGP signature

reply via email to

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