Solved 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:
But on the first line of inArray, it reports:
I suppose it's very basic, but I don't understand why the 2 values are not identical.
KR
Marc -
The first case is an address (
0x....
) / pointer to your char array and in the second case it's one char array of yourchar **
.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 nostd::string
orQString
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'schar *[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 aschar *
. Your code is C not C++ if it makes any difference to the debugging engine. I take you do not declare theinArray()
function anywhere else, e.g. in a.h
file? Make absolutely sure you have recompiled. -
My MSVS debugger displays
array1
andarray2
insideinArray
function aschar**
and their first element ("arp" / "lively") aschar *
That shows, that you pass a pointer to a char pointer array (type of
arr1
) to your functioninArray
, 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 insteadgdb
, 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 ?
-
@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
andchar *array[3]
instead ofchar *array[]
, and also put inconst
s, but it did not alter.Like you, in the autos window I see
array1
as typechar *
, with value"arp"
and in the expansion, say,[2] 'p'
. In the debugger watch window, I enter expressionsarray1
,array1[0]
&array1[2]
. With the following output:As you can see in the watch window, there are two different values for, say,
array1[0]
orarray1[2]
! The first expression showsarray1[2] 'p' char
while the last expression showsarray1[2] "strong" char *
, orarray1
being shown as typechar *
with value"arp"
andarray1[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
andarray1[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 plainchar * []
happens, when being insideinArray
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, thatarray1[2]
is achar
(value'p'
) and it is achar *
(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.