How to get the address of a record variable? #84
Answered
by
edubart
stefanos82
asked this question in
Q&A
-
|
To get the address of a
|
Beta Was this translation helpful? Give feedback.
Answered by
edubart
Jul 21, 2021
Replies: 3 comments 12 replies
-
|
You have printed the address of o.x there, it's 0x5574305962a0, this address is fixed, because it's inside the block of memory of the record. "record" really means a block of memory, so all variables inside a record have their addresses relative to the block of memory address. You can notice the address is also the same as the record address, this is because x is at the very start of the memory block region, so the very first field always has the same address of the record. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I have just confirmed this by adding a new variable in record and it jumps 8 bytes; going through overview documentation, I can see Nelua's I've learned some new today; cheers @edubart 👍 |
Beta Was this translation helpful? Give feedback.
Answer selected by
edubart
-
|
By the way, I have decided to tweak a bit my global configuration settings and use C++ in place of C; here's what I use for settings and here is the actual output from Nelua: Now, if I replace Am I doing well that I use |
Beta Was this translation helpful? Give feedback.
2 replies
-
Nelua compiles to C with some extension, as I said in #73 (comment), . Also some standard C features are not in the C++ spec, but most C++ compilers supports these features anyway, when you use |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I just did. I only left |
Beta Was this translation helpful? Give feedback.
-
|
@edubart I'm currently facing a very interesting issue with Nelua and I need your advice please. I have added another variable in require 'allocators.general'
require 'string'
local Object: type = @record{ x: integer, y: integer }
function Object:__close()
print(string.format('object %p destroyed', self))
general_allocator:delete(self)
end
do
local o: *Object <close> = general_allocator:new(@Object)
print(string.format('object %p created', o))
print(string.format("o.x initial value: %3d, address: %p", o.x, &o.x))
print(string.format("o.y initial value: %3d, address: %p", o.y, &o.y))
o.x = 10
print(string.format(" o.x new value: %3d, address: %p", o.x, &o.x))
endWhen I execute it, I get the following output: This is exactly what I want to see. If I run it with TCC, I see a completely different format of addresses: Now the action is about to begin for me. If I execute Any idea why |
Beta Was this translation helpful? Give feedback.
9 replies
-
|
TCC is severely broken and I compile When you execute Also, I have noticed you add By the way, |
Beta Was this translation helpful? Give feedback.
-
|
It seems the 2nd result is built in 32bit mode(all addresses are <4GB), check the generated c file, it should contains a comment about the real compile command in seconds line (looks like |
Beta Was this translation helpful? Give feedback.
-
The compile command is nearly identical to standard GCC's: It looks like it's built in 32-bit, but it's actually quite confusing; it's a 64-bit ELF file: |
Beta Was this translation helpful? Give feedback.
-
|
Having the address below 4GB hints that could be 32bit build, but does not confirm. In 64bit the addresses can still be below 4GB. |
Beta Was this translation helpful? Give feedback.
-
|
I hope this helps somehow 🤔 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
You have printed the address of o.x there, it's 0x5574305962a0, this address is fixed, because it's inside the block of memory of the record. "record" really means a block of memory, so all variables inside a record have their addresses relative to the block of memory address. You can notice the address is also the same as the record address, this is because x is at the very start of the memory block region, so the very first field always has the same address of the record.