Differences between result of nStrCrc in FW vs FWh

[hidroxid]

Antonio,

I'm having differences between the result of the function nStrCrc() returned with FW 2.1 versus the result with FWh 10.12 (Harbour 2.1).

Have so many files with internal datas verifyed with CRC (created with FW), now when i pass its to FWh, many of my functions show errors in data due the difference of nStrCrc.

I test with nStrCrc16() and HB_CRC32() nothing. Even the result of nStrCrc() differs from HB_CRC32() ...

Is possible get the code of the function nStrCrc() used in FW to compile with my function and use at least the such comparations ?

I will try to isolate a string that show diffs to upload.

Regards.

[hidroxid]

Antonio,

Apparently the bug occurs when use the Chr( 0 ). With the string: "Hola" + Chr( 0 ), i get:

CRC FW 16: 812493129 (ver: 2.1 - 2000/09)
CRC FWh: 254842013 (ver: 10.12)
CRC HB: 4040125282 (ver: 2.1)

I try to change the Chr( 0 ) with any other character but none work.

"Hola" + Chr(0) is a simple example, i cant remove the Char 0.

Solutions ?

Regards.

[Antonio Linares]

Gustavo,

This is the code of FW nStrCrc() (16 bits). Try to compile it with Harbour and lets see if that solves it

Code: Select all  Expand view  RUN

#define     M16 0xA001      /* crc-16 mask */

//----------------------------------------------------------------------------//

static unsigned int wCrc( unsigned char * Buffer, int wLen )
{
    unsigned int wCrc = 0, index, i, c;

    for( index = 0; index < wLen; index++ )
    {
        c = ( unsigned int ) Buffer[ index ];
        c <<= 8;

        for( i = 0; i < 8; i++ )
        {
            if( ( wCrc ^ c ) & 0x8000)
               wCrc = ( wCrc << 1 ) ^ M16;
            else
               wCrc <<= 1;

            c <<= 1;
        }
    }
    return wCrc;
}

HB_FUNC( NSTRCRC ) // cText --> nTextCRC
{
   hb_retnl( wCrc( ( unsigned char *  ) hb_parc( 1 ), hb_parclen( 1 ) ) );
}

 

[hidroxid]

Antonio,

I include your code in FWh and the result is identical to nStrCrc16().

For the string "Hola" + Chr( 0 ) i get 23978 with your code and with nStrCrc16().

And sorry if i mistake, but believe that code is not the same used in FW 16 bits. I compile your code in FW 16 bits with the name nStrCrcNew() and the result is the same compare to FWh ( 23978 ) but not the same between nStrCrc() de FW 16: 812493129 . If the code was the same, i should get the same result. is not?

Please check it and look if really your are write down the correct code.

Best regards

[Antonio Linares]

Gustavo,

Please try this code with Clipper and see if it works fine,

It may be a difference between 16 and 32 bits that has to be fixed

[hidroxid]

Antonio,

Yes!, i test your code with Clipper + FW 2.1 and get the same result that using the function nStrCrc16() with Harbour + FWh 10.12, but not the same using nStrCrc() with Clipper + FW 2.1.

Or you say test only in clipper without FW ?... is same not?.. well i test all again now.

By the way, how i can fix the "difference between 16 and 32 bits" that you wrote ?

Anyway i test again i wrote the results.

[hidroxid]

Antonio,

Test again and get the same result:

Your code nStrCrc() is like nStrCrc16() in Harbour

i believe the problem is that nStrCrc() is to calc the CRC16.

Reading the Help of FiveWin Functions for Clipper it say: "nStrCrc( <cText> ) ... generate a 32 bits CRC checksum value"

Any clue that can help me ?

[Antonio Linares]

Gustavo,

Your code nStrCrc() is like nStrCrc16() in Harbour

As far as I understand you need the same functionality between nStrCrc() in Clipper and nStrCrc16() in Harbour, and you already have it

What is it missing ?

[hidroxid]

Antonio,

Nop, let me resume:

With a simple string: "Hola" + Chr(0), i get:

nStrCrc() -> Harbour + FiveWin: 254842013
nStrCrc16 -> Harbour + FiveWin: 23978
HB_CRC32 -> Harbour + FiveWin: 4040125282
nStrCrc() -> Clipper + FiveWin: 812493129

See? A simple string show difference in CRC function.

The problem? I have sensible data stored (in every customer) with their respective Checksum calculated with nStrCrc() using Clipper + FW. If the Checksum fail, the data is bad. Now, with Harbour + FWh the most data has error because the old CRC of that data differs of the new CRC of the same data, showing error but really is not.

I test the code you suggested and it is the same like nStrCrc16() -> Harbour + FiveWin.
I test other CRC codes but nothing return the same like your function nStrCrc() in Clipper + FiveWin.

I hope you understand me , any way i wrote a simple code to test:

Code: Select all  Expand view  RUN

#include "Fivewin.ch"

#define C_TEXT  "Hola" + Chr( 0 )

FUNCTION MAIN()

#ifdef __HARBOUR__
    ? "nStrCrc Harbour + FiveWin: " + cValToChar( nStrCrc( C_TEXT ) ), ;
      "nStrCrc16 Harbour + FiveWin: " + cValToChar( nStrCrc16( C_TEXT ) ) + CRLF, ;
      "HB_CRC32 Harbour + FiveWin: " + cValToChar( HB_CRC32( C_TEXT ) ) + CRLF
#endif

#ifdef __CLIPPER__
    ? "nStrCrc Clipper + FiveWin: " + cValToChar( nStrCrc( C_TEXT ) )
#endif

RETURN NIL 

Thanks

[Antonio Linares]

Gustavo,

Why don't you assume that all the DATA is bad and then recalculate all news CRCs using HB_CRC32() ?

Surely the CRC values between 16 and 32 bits are differents and its not easy to know where the difference comes from

[hidroxid]

OMG... I will die when tell this to my clients ...

But i understand you comment.

Thank you for the answers!

[Rolaci]

Hi!, check this link, this example and "C" program is clear!, regards. (lib_crc.zip)
Roberto Olaciregui
http://www.lammertbies.nl/comm/software/index.html