How about returning negative value when somethings went wrong?

[somidad]

There are lots of codes throwing a runtime error. For instance,:

throw std::runtime_error( "reed-solomon: parity length incompatible with number of roots" );
throw std::runtime_error( "reed-solomon: input data type too small to contain symbols" );
throw std::runtime_error( "reed-solomon: parity data contains information beyond R-S symbol size" );

I am using ezpwd in GNU Radio. It is a flow-based software defind radio (SDR) platform.

The most radio systems should not stop and crash even if it receives significantly corrupted packets. In such a case, the entire flow of stream will be stopped due to a failure of decoding reed-solomon.

Therefore, I've though about returning negative value for informing 'I (rs) tried to decode a stream, but there occured an error.'

What do you think about it? Do you want me to send a pull request?

Regards, Jeon.

[pjkundert]

Thanks for the recommendations, Jeon.

Since the c++/ezpwd/rs APIs use dynamic C++ containers internally (eg. std::vector), there is the possibility that the code will throw other exceptions, too (eg. due to memory exhaustion). So, you'll need to handle exceptions thrown by the code, indicating various failures to encode or decode.

I wrote various plain "C" wrappers for code which uses ezpwd-reed-solomon's c++/ezpwd/rs interfaces -- see rskey.C and ezcod.C. These catch all exceptions, and return a -1 to indicate an error. Perhaps you could implement a similar plain "C" wrapper for the Reed-Solomon APIs you wish to use, in a similar style? Personally, I've found it better to catch exceptions at the appropriate layer in my own code, rather than checking for error codes from every function call.

If you are encoding a stream of raw data into Reed-Solomon "codewords" of a specific size, there must be some kind of signalling mechanism in your transport to indicate the boundaries of the codeword to the receiver. Otherwise, you won't be able to recognize the beginning or end of the codeword. If you receive some data with neither beginning or ending indicators, you'll need to attempt to position the data into R-S codewords "statistically" -- by trying various amounts of "erasures" padded on either end, and checking to see if the resultant codeword can be decoded (and, how much excess parity remains after the decode procedure, indicating the probability that you guessed correctly). See ezpwd-reed-solomon's c++/ezpwd/corrector for some examples of something like this.

Give me some examples of what your failure modes are, and lets see if there may be some approaches that will better resolve your issue!

[somidad]

I am sorry for answering sooooooooo late. Thank you for your detailed answer.

Fortunately, there is nothing wrong on your library. It's my fault that I feed a signal into a decoder with a wrong timing synchronization. After I fixed synchronization problem, everything is just fine.

So, you can just throw this issue away. :)