How does Visual Studio decide on the field names in a C structure when doing a quick watch on the structure?

Question

How does Visual Studio decide on the field names in a C structure when doing a quick watch on the structure?

Theodore Sung 0

Programming in C. I was curious how/where Visual Studio is determining the field names of a structure when one does a quick watch on the pointer to the structure's memory. The reason is a bit odd but here it is:

we have a client facing structure that is also used internally our API. Internally we want the field to be one name but to the client we want it to be another name. So we've been playing with redefining the field name in various header files but are curious how Visual Studio decides which field name to actually display in Quick Watch or the Watch Window.

Thanks, Ted

Viorel 122.6K Reputation points

2025-02-19T01:01:33.79+00:00

Probably the Visual Studio decides to use the names that were specified in the definition of the structure.
Theodore Sung 0 Reputation points

2025-02-19T01:39:29.0166667+00:00
Let me clarify a bit. main.c looks like this:

#include "testicmo.h"

int main( int nargs, char * argv[] {

foo(); X *xp = calloc( 1, sizeof( X ) );

where testicmo.h looks like this:

#ifndef X_DEFINED

typedef struct _X {

int armi_index ; /* ARM index# - offset in the icmo_vindex_info[] array */ } X ;

#define X_DEFINED

#endif

so according to the definition, I should see armi_index in the debugger.

But I have another C file (call it foo.c and I'll link to the object) that looks like this:

#include "testcmo.h"

void foo() {

X *xp = (X *)calloc( 1, sizeof( X ) ); }

and testcmo.h has

/* Should be defined before include icmo.h : */

#define armi_index armi_index_external

#include "testicmo.h"

/* Should be redefined after include icmo.h : */

#undef armi_index

#define armi_index armi_index_internal

#endif /* CMO_H_INCLUDED */

So when I compile foo.c, the field name is getting redefined but when I compile the main.c, it does not.

How does the debugger know what field name to use for the structure X?

Thanks, Ted
Viorel 122.6K Reputation points

2025-02-19T02:15:16.0233333+00:00

When main.c is compiled, the testcmo.h is not used.
Theodore Sung 0 Reputation points

2025-02-21T18:56:33.3466667+00:00

It seems that compiling with /GL and linking with /LTCG causes the behavior I wanted to see in the debugger. Not sure why these options would affect things, though
Darran Rowe 1,991 Reputation points

2025-02-23T14:59:51.6633333+00:00
Without going into details, this is most likely luck and not something that can be relied on.

As a theory on what is happening, one optimisation available to the linker is to notice that functions can have the exact same binary representation and then remove duplicates. This is enabled with the linker's /OPT:ICF option. The compiler's /Gy and /GL flags, and the linker's /LTCG flag help since this allows the linker to look across multiple object files and make functions into a separatable unit.

To give a little example, suppose there are two functions.

int calculate_int_val(int val1, int val2) { int return_val = 0; //Calculate value. return return_val; } long calculate_long_val(long val1, long val2) { long return_val = 0; //Calculate value in an identical way to //calculate_int_val. return return_val; }

The int and long types have the same representation internally, and so the compiler generates the exact same sequence of instructions for both calculate_int_val and calculate_long_val. The linker is able to remove one of the functions and redirects all the calls from the removed function to the existing function. This saves space. The issue is that there is no guarantee on whether calculate_int_val or calculate_long_val is the one that is kept.

The same thing is probably happening to your code. As surprising as it may sound, two structures with the same name, same memory layout but different member names are not classed as compatible by the compiler. So:

struct s { int value_tu1; };

struct s { int value_tu2; };

These are classed as different, incompatible structures by the compiler. The C standard does clearly state this. This means that normally, the linker would keep all of the functions that work with these structures. However, with the right set of compiler/linker options and luck then it is possible to have things work out.

There are better options for doing this, using a union to choose between two structures but only exposing the public structure as one example. Unions in C allow type punning (C++ states that this is undefined behaviour).

typedef struct test_struct { int a; } test_struct; typedef struct test_struct2 { int my_a; } test_struct2; typedef union test_union { test_struct; test_struct2; } test_union; void use_test_struct(test_struct *ts) { int v = ts->a; test_union *tu = (test_union *)ts; } void use_test_struct2(test_struct2 *ts2) { int v = ts2->my_a; } int main() { test_union tu = { 1 }; use_test_struct((test_struct *)&tu); use_test_struct2((test_struct2 *)&tu); return 0; }

It is possible to cast the struct back to the union. The names used for the structure will be based on the type of the structure you are using to access the memory. External code is also not required to see the full union, just having the externally facing struct will suffice.

As previously stated, this is technically UB for C++, but most C++ compilers will allow this too, especially if they are C/C++ compilers. Visual C++ supports this.

1 answer

Your answer

Viorel 122.6K Reputation points

2025-02-19T01:01:33.79+00:00

Probably the Visual Studio decides to use the names that were specified in the definition of the structure.
Theodore Sung 0 Reputation points

2025-02-19T01:39:29.0166667+00:00

Let me clarify a bit. main.c looks like this:

#include "testicmo.h"

int main( int nargs, char * argv[] {

foo(); X *xp = calloc( 1, sizeof( X ) );

where testicmo.h looks like this:

#ifndef X_DEFINED

typedef struct _X {

int armi_index ; /* ARM index# - offset in the icmo_vindex_info[] array */ } X ;

#define X_DEFINED

#endif

so according to the definition, I should see armi_index in the debugger.

But I have another C file (call it foo.c and I'll link to the object) that looks like this:

#include "testcmo.h"

void foo() {

X *xp = (X *)calloc( 1, sizeof( X ) ); }

and testcmo.h has

/* Should be defined before include icmo.h : */

#define armi_index armi_index_external

#include "testicmo.h"

/* Should be redefined after include icmo.h : */

#undef armi_index

#define armi_index armi_index_internal

#endif /* CMO_H_INCLUDED */

So when I compile foo.c, the field name is getting redefined but when I compile the main.c, it does not.

How does the debugger know what field name to use for the structure X?

Thanks, Ted
Viorel 122.6K Reputation points

2025-02-19T02:15:16.0233333+00:00

When main.c is compiled, the testcmo.h is not used.
Theodore Sung 0 Reputation points

2025-02-21T18:56:33.3466667+00:00

It seems that compiling with /GL and linking with /LTCG causes the behavior I wanted to see in the debugger. Not sure why these options would affect things, though

Answer 1

Bruce (SqlWork.com) 77,926 Volunteer Moderator

typedef's are scoped to the source using them. the debugger uses the symbol table generated for each source, to know what properties a typedef has in that source.

Share via

How does Visual Studio decide on the field names in a C structure when doing a quick watch on the structure?

1 answer

Your answer