Re: [Discuss-gnuradio] Data type between blocks

[Tom Rondeau]

On Sat, Apr 6, 2013 at 8:37 AM, Gong Zhang <address@hidden> wrote:
> Hi,
> I notice that the parameter "gr_vector_const_void_star
> &input_items,gr_vector_void_star &output_items"in the work() method is
> the void* pointer,which don't point to any definite data type.For
> example,the output data type is float32 in the upper block and the input
> data type maybe int8 in the next block.In principle there is no problem
> connecting them because the data is ponited by void*,thus I can cast the
> data into any data type(of course, only makes sense only into
> float32).But connecting them is illegal in GRC.Why would such a
> contradiction?
> Thanks in advance.

Gong,

It's not really a contradiction. The backbone of GNU Radio is the
framework that ships samples between blocks, which means writing and
reading from a buffer. We want that to be as transparent as possible,
so we just look at the buffer as a queue of bytes. But then the block
needs to know what to do with those bytes, so it has to have some
concept of what the actual data type is.

You could do what you say, yes, which is cast the buffer values to
anything that you want in the work function. But that's really
dangerous. If the buffer holds 1000 shorts, that 2000 bytes. If you
read it as floats, though, you will be told that there are 1000 items,
which you would interpret as 4000 bytes. If you tried to read (or,
worse, write) that many bytes, you're out of the bounds of the buffer.
At best, you'll get bogus data. At worst, you'll seg fault.

So this is a convenience to the user. We make the work prototype
transparent to the data type. You just have to work on what data type
you expect. You then use the io_signatures to say that you expect this
many bytes/item so that your item size is always consistent with what
is in the buffers.

If we tried to impose really strict typing rules on the work function
prototypes, it would get out of hand quickly. Simply casting the
pointer is much easier to deal with.

Tom