🔒 Locked

Generate unique labels?

Started by Javelin Jan 18, 2007 at 3:27 AM 14 replies 1.9k views

Original Post

Jan 18, 2007 at 3:27 AM

Hi To make a long story short... I need to generate globally unique labels (the ones you can jump to) in a C program. I have to do this during the preprocessor phase. Is it possible to do this C/C++? I thougt of using the __FILE__ and __COUNTER__ macros, but this will give me a string and not an identifier. This would also include a '.' which is not valid. Any ideas? Thanks!

Javelin

Jan 19, 2007 at 8:27 AM

Bump... :\

rip-off

Jan 19, 2007 at 8:31 AM

Why do you want to do this? Can you show how you would use them?

Aardvajk

Jan 19, 2007 at 9:03 AM

[EDIT] - Please disregard the below, as it is nonsense. Sorry.

I've not come across __COUNTER__ before, but according to this it will just generate the number not in quotes.

I assume you wanted to use __FILE__ to make it unique to the translation unit. I was wondering if this would work:

#define UNIQUE ThisFileIDvoid f(){    UNIQUE##__COUNTER__:}

Just a theory and a bit cumbersome but I can't think of any other ways to do this with the preprocessor.

I, too, am curious as to why you need to do this.

CTar

Jan 19, 2007 at 9:08 AM

How will you choose which one to jump to when it's generated by __COUNTER__?

juanpaco

Jan 19, 2007 at 9:09 AM

Could you add a batch file or something to your pre-build steps that could call a program which would go in to all of your source files and add the unique identifiers?

Bregma

Jan 19, 2007 at 10:41 AM

Quote:
Original post by Javelin
Is it possible to do this C/C++?

Could you paste __LINE__ onto some base string?

--smw

Javelin

Jan 22, 2007 at 3:42 AM

Thank you... :)

However:
What I want to do is a very quick way of getting the address of a caller when inside the called function. Generate unique labels would let me use that label as an address.

* I will never use the label in a jump or similar. Only as a position reference.
* I *can* use the stack, but would rather not...
* I do *not* want to use a string as reference, e.g. __FILE__ or __FUNCTION__

Thanks

jpetrie

Jan 22, 2007 at 7:27 AM

Huh?

As far as I know, only GCC allows you to take the address of a label, and that is an extension (e.g., nonstandard). And I would expect the label would need to be in scope, so you probably can't take the address of any random label the program from a particular function. I'm not clear how you think this will work at all, even if you get past the preprocessor generation phase (which is not possible using only the standard preprocessor functionality).

You're likely going to have to use the stack, or an appropriate OS-level call (there are Win32 APIs that allow you to get this information).

Bregma

Jan 22, 2007 at 8:42 AM

Original post by Javelin
What I want to do is a very quick way of getting the address of a caller when inside the called function. Generate unique labels would let me use that label as an address.
/quote]

man setjmp(3).

--smw

Javelin

Jan 22, 2007 at 8:42 AM

Well...

It's a non standard compiler for a non standard embedded device. I know the technique works since I've tested it. I just need to generate the labels automagicly... ;)

Concerning the scope issue, its possible to declare the label as extern and then you will be able to use it.

I don't say it's the cleanest solution, but quite fast... and that's what I need.

LessBread

Jan 22, 2007 at 4:05 PM

Quote:
Original post by jpetrie
(there are Win32 APIs that allow you to get this information).

There are? That's new to me. What are their names? When I wanted that information, I used the stack and some inline assembler.

Emmanuel Deloget

Jan 22, 2007 at 4:19 PM

Quote:
Original post by LessBread
Quote:
Original post by jpetrie
(there are Win32 APIs that allow you to get this information).

There are? That's new to me. What are their names? When I wanted that information, I used the stack and some inline assembler.

StackWalk64, for example. The entire Debug API is filled with very useful functions - if you plan to distribute your program along with the pdb file :)

Excors

Jan 22, 2007 at 5:06 PM

The _ReturnAddress intrinsic is an easier (and presumably hugely faster, but maybe less accurate) way of finding the caller in MSVC than walking the stack [with StackWalk64]. Not sure whether it's new in VS2005, though.

About labels: are you trying to do something along the lines of

void log(void* caller, char* message) {    printf("%p %s\n", caller, message);}#define LOG(msg) LOG2(CAT(LABEL, __LINE__), msg)#define LOG2(label, msg) label: log(&&label, msg)#define CAT(a,b) CAT2(a,b)#define CAT2(a,b) a##bint main() {    LOG("Test 1");    LOG("Test 2");    LOG("Test 3");}

(using GCC extensions)? In that case, __LINE__ ought to be unique enough, since it only needs to be unique within its source file, and you can avoid using it twice on the same line. But from your explanation, it sounds like that isn't quite what you want.

[Edited by - Excors on January 22, 2007 5:06:10 PM]

Javelin

Jan 23, 2007 at 4:39 AM

Nice to see that many relpies... :)

What I want is to log all memory allocations to detect memory leaks. Therefore, the line number is not sufficient.

There are quite many ways to do this, but we have to do this as fast as possible since the application/system is a bit time critical (and the logging will be there always, not just in debug build).

We can use the stack but hoped for a solution that is faster.

LessBread

Jan 23, 2007 at 1:35 PM

Quote:
Original post by Emmanuel Deloget
Quote:
Original post by LessBread
Quote:
Original post by jpetrie
(there are Win32 APIs that allow you to get this information).

There are? That's new to me. What are their names? When I wanted that information, I used the stack and some inline assembler.

StackWalk64, for example. The entire Debug API is filled with very useful functions - if you plan to distribute your program along with the pdb file :)

I forgot about those. I suppose that could be used to identify the caller.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.