USR for CTU analysis

Hi list,

index::generateUSRForDecl sometimes returns USR names followed by special characters such as

c:@F@UA_memoryManager_calloc#l#l
c:ua_types.c@F@clear_noInit#*v#*1$@S@UA_DataType#

Could someone explain what “#l#l” mean?
And the second case looks quite different from other cases. It would be appreciated if you could give some explanation.

Thanks,
Kihong

Taking a look at USRGeneration.cpp, it seems to me that ‘#l#l’ indicates two (template?) arguments with ulong types.

Gabor

Hi Gabor,

Thanks for your answer.
But this is a C program. What does template mean in C?

Also, ASTImporter sometimes raises “name conflict” even though the function has a unique name and the AST file is in ctu-dir.
When does “name conflict” happen?

Kihong

But this is a C program. What does template mean in C?
That appears to be a simple C function then with two ulong params.

Also, ASTImporter sometimes raises “name conflict” even though the function has a unique name and the AST file is in ctu-dir.
You may get a “name conflict” if two nodes in the merged AST has different definitions.
Here is one example with two TUs:
// a.c
enum A { x, y, z };
// b.c

enum B { z };
Now merging them would result a conflicting definition for the global enum constant z which has the value 2 in a.c and 0 in b.c. This is a warning/error because we cannot answer which value we should use during the analysis.

Gabor

Thanks.

But this is a C program. What does template mean in C?
That appears to be a simple C function then with two ulong params.

But, I don’t always see #types. Most of the time, generateUSRForDecl returns just function names without #type but only a few cases have #type that block CTU analysis from loading the corresponding ASTs. On the other hand, entries in ctu-dir do not contain #type.

Also, ASTImporter sometimes raises “name conflict” even though the function has a unique name and the AST file is in ctu-dir.
You may get a “name conflict” if two nodes in the merged AST has different definitions.
Here is one example with two TUs:
// a.c
enum A { x, y, z };
// b.c

enum B { z };
Now merging them would result a conflicting definition for the global enum constant z which has the value 2 in a.c and 0 in b.c. This is a warning/error because we cannot answer which value we should use during the analysis.

Can this kind of conflicts happen for functions also?

I appreciate your help.

  • Kihong

Most of the time, generateUSRForDecl returns just function names without #type but only a few cases have #type that block CTU analysis from loading the corresponding ASTs.
Maybe those functions does not have a parameter, but I am guessing now.

On the other hand, entries in ctu-dir do not contain #type.

Do you mean that the CTU lib fails to find the function?

Based on the above I suppose there may be something wrong about how you execute the first phase (the generation of the PCH files) of the analysis.
I suggest you to use CodeChecker (https://github.com/Ericsson/codechecker/) to orchestrate the CTU analysis, scan-build is abandoned regarding CTU.

Can this kind of conflicts happen for functions also?

In case of extern visible functions, if you try to CTU analyze only those TUs which normally linked together then it may not. For functions with static visibility, they may have different signatures (and definitions) in the different TUs, so you may have a warning/error then again.