First, thanks to Richard van der Hoff for adding the crc16 routines.
I have a few ideas for crc enhancements/improvements to both crc16 and
crc32. The following is the crc16 API, followed by the crc32 API:
extern guint16 crc16_ccitt(const unsigned char *buf, guint len);
extern guint16 crc16_ccitt_tvb(tvbuff_t *tvb, unsigned int len);
extern guint32 crc32_ccitt_tvb(tvbuff_t *tvb, unsigned int len);
extern guint32 crc32_802_tvb(tvbuff_t *tvb, unsigned int len);
One nice thing about crc16 is that there is a function that allows you to
use it on an arbitrary buffer, not necessarily just a tvbuff_t. It would be
nice if crc32 provided something similar. The 2nd thing I think would be
nice is to add a new function that could take a seed. This would allow you
to compute a crc16/32 on one buffer, then continue the computation if the
entire data is not included in one packet. And the 3rd thing that could be
useful is to have the ability to compute the crc16/32 against a tvbuff_t,
but to be able to specify the offset to the crc16/32 you are trying to
compare against, and specify a value to use in its place. We have crc's
that are initialized to zero, for example, then the crc is computed against
the data, then the crc is added to the data. This means that right now, I
have to copy the data, zero the crc field, then compute it, and it means
having to use tvb_memdup()/g_free(). With this new capability, you could do
in-place computations and avoid the extra copying.
Ok, just some ideas...
- Chris
(P.S. Sorry for the notice that gets attached to the e-mail; I have no
control over this.)
-----------------------------------------
This email may contain confidential and privileged material for the sole
use of the intended recipient(s). Any review, use, retention, distribution
or disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact the
sender by reply email and delete all copies of this message. Also, email is
susceptible to data corruption, interception, tampering, unauthorized
amendment and viruses. We only send and receive emails on the basis that we
are not liable for any such corruption, interception, tampering, amendment
or viruses or any consequence thereof.
