Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Debugger reports what can seem to be inconsistent values just before and at the beginning of a function call

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

Scheduled Pinned Locked Moved Solved General and Desktop
13 Posts 4 Posters 2.2k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Z Offline
    Z Offline
    Zlotz
    wrote on last edited by Zlotz
    #1

    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

    Pl45m4P 1 Reply Last reply
    0
    • Z Zlotz

      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

      Pl45m4P Online
      Pl45m4P Online
      Pl45m4
      wrote on last edited by Pl45m4
      #2

      @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.


      If debugging is the process of removing software bugs, then programming must be the process of putting them in.

      ~E. W. Dijkstra

      1 Reply Last reply
      1
      • Z Offline
        Z Offline
        Zlotz
        wrote on last edited by
        #3

        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" ?

        JonBJ 1 Reply Last reply
        0
        • Z Zlotz

          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" ?

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by
          #4

          @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 **?

          1 Reply Last reply
          1
          • Z Offline
            Z Offline
            Zlotz
            wrote on last edited by Zlotz
            #5

            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 ?

            JonBJ 1 Reply Last reply
            0
            • Z Zlotz

              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 ?

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by
              #6

              @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.

              Pl45m4P 1 Reply Last reply
              3
              • JonBJ JonB

                @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.

                Pl45m4P Online
                Pl45m4P Online
                Pl45m4
                wrote on last edited by Pl45m4
                #7

                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


                If debugging is the process of removing software bugs, then programming must be the process of putting them in.

                ~E. W. Dijkstra

                JonBJ 1 Reply Last reply
                0
                • Pl45m4P Pl45m4

                  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

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by
                  #8

                  @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.

                  1 Reply Last reply
                  0
                  • Z Offline
                    Z Offline
                    Zlotz
                    wrote on last edited by Zlotz
                    #9

                    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 ?

                    jsulmJ JonBJ 2 Replies Last reply
                    0
                    • Z Zlotz

                      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 ?

                      jsulmJ Offline
                      jsulmJ Offline
                      jsulm
                      Lifetime Qt Champion
                      wrote on last edited by
                      #10

                      @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"

                      https://forum.qt.io/topic/113070/qt-code-of-conduct

                      1 Reply Last reply
                      0
                      • Z Zlotz

                        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 ?

                        JonBJ Offline
                        JonBJ Offline
                        JonB
                        wrote on last edited by JonB
                        #11

                        @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....

                        Pl45m4P 1 Reply Last reply
                        0
                        • JonBJ JonB

                          @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....

                          Pl45m4P Online
                          Pl45m4P Online
                          Pl45m4
                          wrote on last edited by Pl45m4
                          #12

                          @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


                          If debugging is the process of removing software bugs, then programming must be the process of putting them in.

                          ~E. W. Dijkstra

                          JonBJ 1 Reply Last reply
                          1
                          • Pl45m4P Pl45m4

                            @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

                            JonBJ Offline
                            JonBJ Offline
                            JonB
                            wrote on last edited by JonB
                            #13

                            @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.

                            1 Reply Last reply
                            0

                            • Login

                            • Login or register to search.
                            • First post
                              Last post
                            0
                            • Categories
                            • Recent
                            • Tags
                            • Popular
                            • Users
                            • Groups
                            • Search
                            • Get Qt Extensions
                            • Unsolved