3 ms·
Sure, but you can't know what that number is. It's almost certainly not 1234, and since it's an auto allocated var with local scope, it's probably on the stack
by robotresearcher 6y ago
Sure, but you can't know what that number is. It's almost certainly not 1234, and since it's an auto allocated var with local scope, it's probably on the stack unless it's been optimized elsewhere, so it's dynamic, and exists only for the lifetime of each run of a(). You might figure out some evil way to get it for some implementation, but I don't think the C spec gives you a reliable way. That's what I mean by 'legitimate'.
Even if you modified the code of a() to pass out the address of x to a caller, they can't safely use that pointer and the actual behavior is undefined. x does not exist outside of a call to a().
- sanxiyn 6y agoI think you are right there is no reliable way, but C specification does not disallow unreliable programs. It only disallows nonconforming programs. Compilers can't optimize a() to b() under pointers-are-integers model. It may be linked to code like c(): void c() { int random = generate_random_number(); int* address = (int*)random; *address = 4; } In real machines, c() randomly overwrites memory with 4, in particular memory of x whose value will change from 5 to 4. In C abstract machine, c() randomly overwrites memory with 4, but it can never overwrite memory of x, because memory of x does not have integer address. Therefore compilers can optimize a() to b().