For some reason, writing null pointers into a double pointer(as seen below) seems to crash the executable. I cannot figure out why. Additionally, it isn't immediately exiting execution either, which is just stranger. Am I doing something wrong or this a bug outside of my control?
' fbc.exe -target win64 "code.bas"
dim pointers as ZString ptr ptr
pointers = allocate(32)
'print "Not crashed yet." ' This seems to rescue the program from its crash state, which is... strange, to say the least. Uncomment it to prove it.
scope
print "Entered scope." ' Without "not crashed yet," it crashes somewhere right before here...
dim i as uinteger
for i = 0 to 31
' Commenting the below line causes the program to work absolutely flawlessly, even without the first print statement.
pointers[i] = 0 ' Allocate(-1) also causes a crash, so it's not because my pointer isn't correct. I /think/.
next i
print "Exiting scope."
end scope
print "This is some garbage text."
print "It's completely worthless."
print "I'd be surprised it didn't crash by now."
print "Two more for good measure."
print "Eaaauahgsuiadhgia."
dim i as uinteger
for i = 0 to 31
if (pointers[i] <> 0) then
print "Pointer";i;" is non-zero!"
end if
next i
print "Somehow this almost as intended worked." ' There is an immense delay before exit, but it... does work?
end -1 ' This delay disappears if you remove the pointers[i] line above. I don't get it either.
I'd rather you not look at this, but it does contain a more complex example of exactly what's going wrong, and where I first discovered this. Entire project file:https://files.catbox.moe/su7z87.7z
To put it a different way:
allocate(32) allocates 32 bytes, not 32 pointers. 32 bytes is either 8 or 4 pointers depending on if you're compiling 32-bit or 64-bit. So accessing anything above pointers[7 or 3] may cause problems.
You can either use
allocate(32 * sizeof(*pointers))
or create a FB array
Dim pointers(31) as zstring ptr (use () brackets to access pointers, not [] brackets. ie pointers(i) = 0)
to fix it
If you having these problems the first time this code executes, that would suggest you've done the same oversight elsewhere in your code which has already broken things enough before this code runs
code.c: In function 'main':
code.c:37:94: warning: '__builtin_memset' writing 256 bytes into a region of size 32 [-Wstringop-overflow=]
37 | *(char**)((uint8*)POINTERS$0 + ((int64)I$1 << (3ll & 63ll))) = (char*)0ull;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
code.c:26:22: note: destination object of size 32 allocated by 'malloc'
26 | void* vr$2 = malloc( 32ull );
| ^~~~~~~~~~~~~~~
Uhm, just for reference, please explain like I'm 5 next time. I have no clue what you pointing that out meant, other than "yeah my allocation is wrong somehow."
adeyblue wrote: ↑Feb 14, 2024 0:29
To put it a different way:
allocate(32) allocates 32 bytes, not 32 pointers. 32 bytes is either 8 or 4 pointers depending on if you're compiling 32-bit or 64-bit. So accessing anything above pointers[7 or 3] may cause problems.
You can either use
allocate(32 * sizeof(*pointers))
or create a FB array
Dim pointers(31) as zstring ptr (use () brackets to access pointers, not [] brackets. ie pointers(i) = 0)
to fix it
Thanks. I feel really stupid for not realizing it was BYTES and not pointers.
I'm not sure how FreeBASIC handles variables, but I really don't want to keep throwing my values onto the stack, which is what C does if you define a variable. Since I know this thing transpiles into C, I figured it'd just copy that behavior over.
Before I close the thread for good, I have a quick question. While *nameOfPtrVariable will work in sizeOf(), I'm curious if integer or uinteger can act as universal replacements. The thinking is that 64-bit platforms will have both 64-bit pointers and 64-bit integers. Likewise, all 32-bit platforms should have 32-bit pointers and 32-bit integers. Are there any exceptions I haven't accounted for, or would this work in all cases?