Hi Eugene,

that sounds like a bug, and a fix, indeed!

I'd immediately go ahead and just replace the int by uint32_t (which
happens to be the thing we want to use here, considering the degree
self-limits to 32).


But: I know this has been around 0.75 eterneties; Michael even fixed
some compiler warning in glfsr.cc last year; I want to be sure we're not
breaking anything hence I'm, hereby asking around:


was there a rationale behind having signed intage here?


Best regards,

Marcus



On 09.08.2016 02:29, Eugene Grayver wrote:
>
> Note: It is, of course, possible to trick the blocks into working by
> passing in negative values (n - 2**32), but it is not elegant.
>
>
> ________________________
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> ________________________
>
>
>
> ------------------------------------------------------------------------
> *From:* Eugene Grayver
> *Sent:* Monday, August 8, 2016 5:22 PM
> *To:* [email protected]
> *Subject:* Re: Bug in digital::glfsr_source_b
>  
>
> Note: same issue with descrambler_bb and scrambler_bb.  The
> digital.lfsr block is correct.
>
>
> ________________________
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> ________________________
>
>
>
> ------------------------------------------------------------------------
> *From:* Eugene Grayver
> *Sent:* Monday, August 8, 2016 2:47 PM
> *To:* [email protected]
> *Subject:* Bug in digital::glfsr_source_b
>  
>
> I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The
> input types for mask and seed should be 'unsigned int', not 'int'.
>  Currently it does not allow 32-bit values, only 31-bit values.  While
> somebody is fixing that, they should also make 'length' an optional
> input to have the LFSR restart after fewer than 2^degree outputs.
>
>
> ________________________
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> ________________________
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to