strtol strange behaviour

[baptistou]

Hi all there,

I've been using strtol function for a while in my program without any error. I updated the SVN repository folder on my computer this morning, and now without having changed anything from my program, everytime I compile I get:

Creating object file for sentinel.c

sentinel.c: In function 'Sentinel_ValidateChecksum':

sentinel.c:222: warning: pointer targets in passing argument 1 of 'strtol' differ in signedness

Any clue of what's happening in there? Here is the part of my sentinel.c causing these warnings:

/////////////////////////////////////////////////////////////////////////////

// this takes a string, and validates it againts the checksum

// at the end if the string.

// returns 1 checksum OK -1 bad checksum -2 checksum not found in string

/////////////////////////////////////////////////////////////////////////////

s8 Sentinel_ValidateChecksum(u8 *strPtr,u32 len)

{

	u8 calculatedChecksum;

	u8 writtenChecksum[3];

	char *next;

	u8 readChecksum;

	u8 c;

	u32 p;


	calculatedChecksum = Sentinel_GenerateChecksum(strPtr, len);


	p = 0;

	c = 0x00;


	while ((c != '*') && (p < len)) {

		c = strPtr[p];

		p++;

	}


	if (p > len - 2) {

		//DEBUG_MSG("nmea_validateChecksum p > len -2");

		return -2;

	}


	writtenChecksum[0] = strPtr[p];

	writtenChecksum[1] = strPtr[p+1];

	writtenChecksum[2] = 0x00;


	readChecksum = strtol(writtenChecksum, &next, 16);


	if (readChecksum == calculatedChecksum) {

		//DEBUG_MSG("nmea_validateChecksum checksum OK");

		return 1;

	}


	//DEBUG_MSG("S-- wrong checksum (read %x calculated %x)\n", readChecksum, calculatedChecksum);

	//DEBUG_MSG("%s \n", strPtr);

	return -1;


}

[nILS]

Seems like the compiler is complaining that your string is u8* = unsigned char* while it's expecting char* (default would be signed iirc).

Why don't you just do sth like

readChecksum = (strPtr[p]-48)*10 + (strPtr[p+1]-48);

and not bother with strtol?

[baptistou]

Hi nILS,

I'm using strtol as it handles hexadecimal values, and my checksum are hexadecimal.

I can't see why strtol has changed its behaviour from between the two version of the SVN folder. Also, now that I modified the other files of my project (and the compiler had to rebuild the .o files), I have this error with the function strncpy also everywhere.

Has something changed in the declaration of the "u8" "u16" etc. ?

It looks like "u8" are not equal to "char" anymore...

Baptistou

Edited October 26, 2010 by baptistou

[nILS]

I'm using strtol as it handles hexadecimal values, and my checksum are hexadecimal.

Well, it would be fairly easy to adjust my example to that ;)

Has something changed in the declaration of the "u8" "u16" etc. ?

It looks like "u8" are not equal to "char" anymore...

u8 has never been char. Afaik, it's always been unsigned char.

[baptistou]

I agree I could easily add a function converting strings to hexadecimals.

I didn't take care before today that u8 was unsigned while char is, but I don't understand why I didn't have any warning before updating my SVN folder.

Anyways, how do I pass an unsigned variable to a function requiring a signed one?

[nILS]

By type-casting it.

[philetaylor]

I am guessing that you always had the warnings but the compiler didn't bother to tell you before :)

One of the recent changes that TK has made is add -Wall to the global CFLAGS (in $MIOS32_PATH/include/makefile/common.mk)

This causes GCC to enable ALL warnings (including signed/unsigned mismatch) which makes debugging easier especially as a signed char can only store a 7 bit value (positive or negative) whereas unsigned is 8 bit positive only and the difference can lead to all sorts of problems !!!

Cheers

Phil

[TK.]

It's great to have such warnings.

E.g., in MBSEQ I had to fixed 100s of warnings (took ca. 1 hour), but I found a potential bug which could happened in the past due to function calls with incomplete parameter list (-> random behaviour)

I never noticed this before as I forgot to include the header file into the .c code -> accordingly the C compiler allowed me to pass any parameter w/o producing an error about an "undeclared function" or "inappropriate usage".

Due to this experience I decided to enable warnings for everybody.

Sorry for the inconvenience - you would really like the change if it would have warned you about *THE BUG* that infrequently happened in the past and that you never reproduced during long debugging sessions before. ;)

Best Regards, Thorsten.

[baptistou]

Thanks guys, as a newbie I do agree to say that warnings are definitely useful: they teach you how to code properly!

Best regards, Baptistou