problems with stncmp use

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i am getting errors for using string compare functions of string.h

char m1[9]="00000000\0";
unsigned char numb[9]="00000000\0";
if (strncmp(m1,numb1,8)==0)

i get this error

Error	8	expected 'const char *' but argument is of type 'unsigned char *'	

how can i solve this, I am using avrstudio5 and my target is Atmega644

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
char m1[9]="00000000\0";

Thats 10 chars not 9!

Anyway, the clue is in the error message! Use unsigned char for m1.

And don't you get an unresolved error for numb1?

Three errors in three lines of code is 100% hit rate... well done ;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you are using a string, I would expect you to use char rather than 'unsigned char'.

Change the type of numb[] and it should be happy. And you should be too.

An untidy kludge is simply to cast:

if (strncmp(m1, (char*)numb1, 8) == 0)

Why are you using strncmp() in the first place?
Surely strcmp() would be more appropriate?

Edit. No. Greg, it is perfectly legal to initialise an array with a string. The compiler simply omits the NUL if it does not fit. One of the features of C that frustrate hair growth! In this particular case he has got an embedded NUL in the string, so he would not get caught by the C gotcha.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
char numb [9]

solved the issue.
actually i typed the declaration of numb1 and mistyped, its 1 in the code here,

regarding the space for null, i am embedding that here and C will omit the null that it had to add, the reason is that . i know its odd to do it that way but i have done that intentionally for some other reason

Thank you Greg and David!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really David? '\0' is null and takes one byte. "\0" is what it says, and takes two bytes.

Or at least it does with the compiler at work. I'll have to check later with the one at home to see if the '\' needs escaping to make it a literal.

I'm easily confused having to use so many languages and different compilers.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
"\0" is what it says, and takes two bytes.
Yes, but if you write
char foo[1] = "\0"; 

then only the first of the two bytes is copied to foo.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, good point!

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I write:

char name[5] = "David";

there is no room to add the NUL. I have not exceeded the array bounds because David is only 5 letters.

char name[] = "David";

will allocate 6 bytes for the array. i.e. it appends the NUL and allows for a "string" initialiser needing the terminating NUL. 'Flexible' arrays are a Godsend.

Of course the first example will cause chaos with every string function because they will not see a NUL.

A 'nice' compiler might issue a Warning for the 'array not having space to append a NUL'. But it is perfectly legal to keep quiet.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, I agree. I was thinking about your 'No.' and mis-interpretting what you were attempting to point out. My mistake.

Quote:
The compiler simply omits the NUL if it does not fit.
I didn't appreciate what you were implying here.
Quote:
In this particular case he has got an embedded NUL in the string
This is what I'm (or rather was) questioning. As a ' is treated very differently from a ". As Stefan has already replied, there is no room for that, if it's a literal.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can insert a NUL in the middle of a quoted string. It is just the same as any other escaped number. e.g. \033

It just gets messy to read when you have embedded literals. All the same strings are easier than a sequence of numbers in an initialiser.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're quite right :)
Funny how you miss things when you've never done it yourself.
That is such bad practice I'm surprised more people don't do it.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, a sequence of "\0" in a couble-quote-enclosed string will be inperpreted as an escape sequence for the octal value zero, which will again be just one byte long. Ditto for "\00" or "\000".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg's original assessment was correct, that is a 10 character string: 8 ASCII Zeros, a NULL character, and then a second NULL character added automatically.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Of course you can do things in many ways:

unsigned char numb[9]="12345678\0";      // size is 9 
unsigned char numb[9]="123456789";       // size is 9 no NUL 
unsigned char numb[9]="12345678";        // size is 9 
unsigned char numb[]="12345678";         // size is 9 
unsigned char numb[10]="12345678\0";     // size is 10 
unsigned char numb[]="12345678\0";       // size is 10 

The convention is that the ascii character '\0' is called NUL. All the non-printing ascii characters have names e.g. SOH, ESC, TAB ...
(void*)0 is called NULL.

The two terms are very different. It is very common to use the 'null pointer' NULL in a C program.

David.