• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 22 subscribers
  • Views 3975 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

string definition

PT TAM

I have following code but find that x and y are the same value on the debugger. viewing ARM assembly review that the memcpy use same string address.

#define A "\xA0\x00\x01"
#define B "\xA0\x00\x02"
memcpy(x, A, sizeof(A)-1);
memcpy(y, B, sizeof(B)-1);

If I change
#define A "\xA0\x01\x01"
#define B "\xA0\x02\x02"
it will be OK.

Tam

Parents
  • 0 in reply to Karl Hamsher

    My problem is following two definitions are the same according to the compiler.

    #define A "\xA0\x00\x01"
#define B "\xA0\x00\x02"

    I think Daniel and Henry are right that compiler treats them as strings terminated after \xa0. and merge them together.

    In my design, both A and B are communication header that I need to compare, ie

      if( memcmp( in_buffer, A, sizeof(A))==0)
  {
    handle_cmd_A();
  }
  else if( memcmp( in_buffer, B, sizeof(B))==0)
  {
    handle_cmd_B();
  }
  else
  {
    ...
  }

    Is there any workaround solution? Thanks

Reply
  • 0 in reply to Karl Hamsher

    My problem is following two definitions are the same according to the compiler.

    #define A "\xA0\x00\x01"
#define B "\xA0\x00\x02"

    I think Daniel and Henry are right that compiler treats them as strings terminated after \xa0. and merge them together.

    In my design, both A and B are communication header that I need to compare, ie

      if( memcmp( in_buffer, A, sizeof(A))==0)
  {
    handle_cmd_A();
  }
  else if( memcmp( in_buffer, B, sizeof(B))==0)
  {
    handle_cmd_B();
  }
  else
  {
    ...
  }

    Is there any workaround solution? Thanks

Children
  • 0 in reply to pt tam

    "My problem is following two definitions are the same according to the compiler."

    No - not according to the Compiler.

    What people are talking about is that the way that the Debugger displays the data.

    The suggestion is that the Debugger is assuming that your data is supposed to be a null-terminated 'C' string, and so is terminating its display of the string at the first null.

    You need to inspect the memory directly to be sure of what's going on.

  • 0 in reply to pt tam

    An alternative might be:

    #define HEADER_0 0x0A
#define HEADER_1 0x00

#define MSG_TYPE_1 0x01
#define MSG_TYPE_2 0x02

if( (in_buffer[0]==HEADER_0) && (in_buffer[1]==HEADER_1) )
{
   // We have detected the start of a header
   // Now check which type of message it is

   if( in_buffer[2]==MSG_TYPE_1 )
   {
      // It is a Type-1 message
   }
   else if( in_buffer[2]==MSG_TYPE_2 )
   {
      // It is a Type-2 message
   }
}
    This would be preferably anyway if you have several message types, as you can now use a switch to select them!

  • 0 in reply to Andy Neil


    The suggestion is that the Debugger is assuming that your data is supposed to be a null-terminated 'C' string, and so is terminating its display of the string at the first null.
    You need to inspect the memory directly to be sure of what's going on.


    I am sure that it is a compiler problem because I have checked the asm listing that the compiler only generate one constant string.

    Besides, the asm listing shows both memcmp() use pointer pointing to the same location in its second parameter.

     if( memcmp( in_buffer, A, sizeof(A))==0)
 {
 }
 else if( memcmp( in_buffer, B, sizeof(B))==0)
 {
 }

  • 0 in reply to pt tam

    "I am sure that it is a compiler problem because I have checked the asm listing that the compiler only generate one constant string."

    If these 'arrays of char' are treated as string literals then they are identical up to the nul terminator. So, I guess it may be reasonable for the compiler to disregard the third character and merge the literals. Or, it may be that the compiler is being a bit too clever for its own good in this case.

  • 0 in reply to John Donaldson

    Yes, I think the compiler is here a little to clever. We will re-work the string merging in the CARM compiler, so that these strings are not identical anymore.

    Reinhard