This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/MSP432P401R: Compiler/MSP432P401R: string passed into function is ok before call, appears immediately truncated inside call (the variable is used as read only) but is not truncated when returned.

Part Number: MSP432P401R

Tool/software: TI C/C++ Compiler

Hi,

 I am restarting this. I cleaned up my code and the problem remains.

 Strings are truncated to 10 chars when passed in a call across files, i.e. the call is in one c file, the called function is in another c file.

status = setRegister(g_board, g_category, g_group, g_device, g_register,g_field,value);

 I tried changing the API but variable string is still truncated inside the call but remains full length in the caller's context,

i.e. I tried both of these as the API:

int setRegister(char board[LABEL32],   char category[LABEL32],   char group[LABEL32],      char device[LABEL32],  char Register[LABEL32],     char field[LABEL32],     int value);

int setRegister(char *board,   char *category,   char *group,      char *device,  char *Register,     char *field,     int value);

When the string parameter is greater than 10 chars it is truncated to 10.

  • Exactly how do you know you have this problem?  What are you looking at?  

    For the source file which contains the problem call, please submit a test case as described in the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • I am using the CCS debugger and I am looking at the variable before the call, and the variable inside the call, and the variable after
    (not that is should change but anything can happen when passing pointers).

    Before:
    group = "OUTPUT_MEAURE"
    field = "ADC_SS_MODE"

    I pass the vars which are char group[32], char field[32].

    Inside call:
    *group_ptr = "OUTPUT_MEA"
    *field_ptr = "ADC_SS_MOD"

    After return from call:
    group = "OUTPUT_MEAURE"
    field = "ADC_SS_MODE"

    I know it is not an anomaly of the debugger because I do string compares to match inside the called function (this is a lookup function) and
    "ADC_SS_MODE" doesn't equal "ADC_SS_MOD", which is how I discovered the problem in the first place.
  • The problem with handing off a compiler test case is this is a thousand lines of code in a dozen c files for a bespoke embedded board and
    I/O needs to happen before the path is triggered.
    Not that I couldn't subset the code, its just that it would take time.
  • Note: I can work around the problem by using global variables instead of function variables.
  • Robert,

    Looks like you have asked the same question in another post: e2e.ti.com/.../2523022

    It will be really helpful if you post a question in one place and not repeat the question in other posts. This will allow us to answer all the questions in a timely manner.

    I will post the same response here and let's keep the conversation of this thread here as the above linked thread was on a different topic.

    "Not sure if you have already done this, but check what the allocated memory is for where the pointer is pointing. If you have an array that the pointer is pointing to, check the size of the array. If you have used malloc check what the size of the memory that is requested."

    Thanks,
    Sai
  • sorry, I thought it was me, so I said "fixed" when it wasn't, and then I restarted the issue.
    my bad.
  • robert schaefer said:
    The problem with handing off a compiler test case is this is a thousand lines of code in a dozen c files

    I don't plan to run the code.  I plan to inspect the compiler generated assembly for problems.  That is why I don't need all the source.  Just the one file I requested in my previous post.  You'll spend more time reading the article on how to do it, than actually doing it.

    Thanks and regards,

    -George

  • What happens if you just declare the arguments as char * and pass the address of the first element?

    (Could the debugger be truncating it? what does strlen() say?)
  • robert schaefer said:
    When the string parameter is greater than 10 chars it is truncated to 10.

    Using CCS 8.0.0.00016 found that the debugger is only showing the first 10 characters of char * variables in the Variables view, as shown in the above example:

    The memory browser is displaying the full string length, and strlen() has returned the full string length, and thus for this example the issue is with the debugger displaying only the first 10 characters of char * variables in the Variables view.

    I can't find any CCS debugger option to cause the Variables view to display longer strings. I did find the old thread Local, Watch Strings in CCS Debugger which for CCS 4 said:

    Keep in mind that watch window is hard coded to only read 10 characters of a char *.

    The example project is attached MSP432_string_truncation.zip

  • I'll run some more tests.

  • Ok, Keith you are a genius for suggesting strlen(). Thank you!

    I've got a non-printing character on the end of my comparison key "ADC_SS_MODE" fails to compare against "ADC_SS_MODE "

    The CCS debugger is terrible for stopping at 10 chars (I've wasted a day on this).