Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call



  • Hi all

    Here is my C code, run on the Qt-Creator debugger:

    char** inArray(char* array1[], int sz1, char* array2[], int sz2, int* lg) {
        // some things
    }
    
    int main()
    {
        char* arr1[3] = { "arp", "live", "strong" };
        char* arr2[5] = { "lively", "alive", "harp", "sharp", "armstrong" };
    
        int lg = 3;
    
        char** res = inArray(arr1, 3, arr2, 5, &lg);
    }
    

    On the line char** res = inArray(arr1, 3, arr2, 5, &lg); the debugger reports:
    alt text

    But on the first line of inArray, it reports:
    alt text

    I suppose it's very basic, but I don't understand why the 2 values are not identical.

    KR
    Marc



  • @Zlotz

    The first case is an address (0x....) / pointer to your char array and in the second case it's one char array of your char **.

    Arrays in C/C++ are stored in memory by using the pointer to first element. This is why you get the first / starting element inside your function - because you've passed the address of your array = address of first element = " arp"

    Is there a reason why you use char ** and no std::string or QString arrays?

    EDIT:
    To change or access the actual array use
    *array[0] for example.



  • What do you mean by "my char**" ? array1 ? The return of inArray ?

    OK but, as arr1 has the same type in main than array1 in inArray, why what you write doesn't apply to the first case ?
    Does the char*[] of main kind of becomes a char** to the debugger's eye on the call ?

    It's an exercise, I didn't decide the type of the function.

    What do you mean by "actual array use" ?



  • @Zlotz
    The clue/reason will lie in the Type column in the debugger. In your first screenshot I can (just) see it's char *[3]. Redo your second screenshot to show what Type the debugger using there? char **?



  • No. It's char*.

    But I may start understanding.

    Do you mean that the debugger, for any reason, interprets the data differently when in the called function, but at least tells how it interprets the data ?



  • @Zlotz said in Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call:

    No. It's char*.

    And that is your problem here. And, yes, the debugger display stuff can be a bit different from what you might think from looking at your code.

    Having said that, I'm not sure why your char* array1[] parameter declaration is coming out as char *. Your code is C not C++ if it makes any difference to the debugging engine. I take you do not declare the inArray() function anywhere else, e.g. in a .h file? Make absolutely sure you have recompiled.



  • My MSVS debugger displays array1 and array2inside inArray function as char** and their first element ("arp" / "lively") as char *

    That shows, that you pass a pointer to a char pointer array (type of arr1) to your function inArray, which is also stated here:
    https://stackoverflow.com/questions/32377418/how-many-ways-are-there-to-pass-char-array-to-function-in-c



  • @Pl45m4
    Your MSVC behaviour is what I would expect. So I assume OP is instead gdb, and then I don't understand why it is showing as he says it is.



  • Well, I guess that the debugger shows only the first value of the array for the same reason we have to pass lengths of arrays as parameters in C.

    It's OK for me. Must I do something to close the topic ?


  • Qt Champions 2019

    @Zlotz said in Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call:

    It's OK for me. Must I do something to close the topic ?

    "Topic Tools/Mark as solved"



  • @Zlotz
    You may be happy to have closed this, but I decided to do some investigations myself, as it's bothering me!

    I am Ubuntu, gcc 9.3.0, gdb 9.2. I made a C-only project (also tried as CPP project, no difference). I confirm that I see the same behaviour as you show in your screenshots, and note this is different from what @Pl45m4 reported in MSVC.

    I also tried declaring the parameter as char **array1 and char *array[3] instead of char *array[], and also put in consts, but it did not alter.

    Like you, in the autos window I see array1 as type char *, with value "arp" and in the expansion, say, [2] 'p'. In the debugger watch window, I enter expressions array1, array1[0] & array1[2]. With the following output:

    Screenshot from 2020-10-15 08-44-59.png

    As you can see in the watch window, there are two different values for, say, array1[0] or array1[2]! The first expression shows array1[2] 'p' char while the last expression shows array1[2] "strong" char *, or array1 being shown as type char * with value "arp" and array1[0] being shown as exactly the same!

    I see this as "wrong" in gdb, and you are entitled to complain about "inconsistent values" here! There is perhaps an explanation of this behaviour out there under gdb, but I don't know what words to use to Google for it....

    At some level, the fact that array1 and array1[0] have the same memory address may be related to the issue.

    Now, if one of our resident C++ experts would care to comment on this gdb behaviour, which seems brain-damaged to me, I should be most interested to read....



  • @JonB said in Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call:

    I see this as "wrong"

    I wouldnt say it's wrong, it's just weird or somehow confusing since arrays are passed to function by passing the (pointer to / address of) first element. So, if the debugger only sees the first element, the data type char * would be correct in this case.

    @JonB said in Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call:

    char **array1 and char *array[3] instead of char *array[]

    They are similar but not the same nor (directly) interchangeable. A char ** can only be a pointer to one element and can not replace the whole array structure, since you need at least some length parameters or any size :)

    And I guess this is exactly what QtC does. The function gets an array of char pointers, which is a pointer to its first element itself. This is passed to the function and used as char *[]. It depends how QtC debugger (on linux gdb) interprets this parameter and perhaps any conversion to plain char * [] happens, when being inside inArray function?! And maybe Visual Studio and MSVC are "smarter" or interpret this structure differently...

    Interesting stuff to read :)
    http://www.lysator.liu.se/c/c-faq/c-2.html



  • @Pl45m4
    I do see it as "wrong". The debugger shows, in two different places, that array1[2] is a char (value 'p') and it is a char * (value "strong"). That's just plain "wrong". And btw I don't think this has anything to do with "QtC debugger", Qt Creator just gets its information from the debugger, so (I assume, though untested) this is 100% a gdb vs MSVC issue.


Log in to reply